Title says it all. Is there anything wrong with await Task.Run(() => semaphore.WaitOne());
? System.Threading.Semaphore
isn't thread-affine, so I wouldn't think there would be a problem. I know that the SemaphoreSlim
class is available, but I need to do cross-process synchronization, and SemaphoreSlim
doesn't do that.
Or can/should I create my own custom type of WaitHandle
?
If you're trying to keep the UI responsive while waiting for the semaphore here, it might make sense, but there's a catch: "Semaphores don't have owners". If you share the semaphore between two processes, and the other process crashes without calling
Semaphore.Release()
, the ownership over the shared resource will be lost. The remaining process may not be able to acquire it again.IMO, the
Mutex
semantic would be more appropriate here, but withMutex
you'd need thread affinity. Perhaps, you can acquire the mutex, access the resource and release it on the same thread:If that's not possible (e.g., because you need to access the shared resource on the main UI thread), you could use a dedicated thread for the mutex. This can be done with a custom task scheduler, e.g. Stephen Toub's
StaTaskScheduler
withnumberOfThreads:1
(the helper thread doesn't have to be made STA in this case):Updated, if you're concerned about WinRT (i.e., .NET for Windows Store Apps) or Windows Phone, then
Task.Factory.StartNew
w/TaskCreationOptions.LongRunning
is still there, you can use it instead ofnew Thread()
withStaTaskScheduler
or something like myThreadWithSerialSyncContext
whenever you need a background thread with affinity.