K
Ken Durden
I'm setting up an interface where clients must perform external
locking before calling certain commands. I do this to force them to
specify the duration the action they performed must persist before any
other threads can be allowed to perform some action.
My object exposes a Mutex which is locked via a IDisposable-Sentry
class. I want to throw an exception if certain functions are called
without this Mutex already being locked, but I cannot figure out any
way to safely check whether the mutex is already locked by the current
thread.
a.) I could attempt to lock the object with a 0 ms timeout. If this
fails, I know the client has not locked the object down externally as
required. If this succeeds, however, the mutex could have simply been
available.
b.) I could call Release on the mutex, if this throws an exception I
know the client has not locked it prior to calling the function. If it
doesn't throw, however, I have unlocked the mutex and allow the
possibility for another client to lock it down before I can re-acquire
it.
c.) I could have my IDisposable-Sentry class which performs the
locking, actually perform 2 locks, and then I could use method b to do
the locking and unlocking. This seems like it would work, but I'm
worried about the efficiency of repeated unnecessary unlocking and
locking.
d.) I could have my IDisposable-Sentry class which performs the
locking, set an internal variable indicating that it has locked the
mutex. I can check this efficiently and without introducing any subtle
effects on the mutex; but the extent to which it is actually
disassociated from the mutex bothers me.
I understand that checking whether a mutex is locked by the current
thread is a potentially abused operation, since clients could do
things like:
// Skip this operation if currently locked
if( !locked )
{
lock(); // ka-blam, long timeout inside time-sensitive code
}
But, this is simply dumb coding, and a lock(0) should have been used
instead.
I was hoping for either a .NET API function, or even a Win32 API
function that can take in the internal HANDLE and tell me whether the
current thread owns it or not.
Thankee-sai,
-ken
locking before calling certain commands. I do this to force them to
specify the duration the action they performed must persist before any
other threads can be allowed to perform some action.
My object exposes a Mutex which is locked via a IDisposable-Sentry
class. I want to throw an exception if certain functions are called
without this Mutex already being locked, but I cannot figure out any
way to safely check whether the mutex is already locked by the current
thread.
a.) I could attempt to lock the object with a 0 ms timeout. If this
fails, I know the client has not locked the object down externally as
required. If this succeeds, however, the mutex could have simply been
available.
b.) I could call Release on the mutex, if this throws an exception I
know the client has not locked it prior to calling the function. If it
doesn't throw, however, I have unlocked the mutex and allow the
possibility for another client to lock it down before I can re-acquire
it.
c.) I could have my IDisposable-Sentry class which performs the
locking, actually perform 2 locks, and then I could use method b to do
the locking and unlocking. This seems like it would work, but I'm
worried about the efficiency of repeated unnecessary unlocking and
locking.
d.) I could have my IDisposable-Sentry class which performs the
locking, set an internal variable indicating that it has locked the
mutex. I can check this efficiently and without introducing any subtle
effects on the mutex; but the extent to which it is actually
disassociated from the mutex bothers me.
I understand that checking whether a mutex is locked by the current
thread is a potentially abused operation, since clients could do
things like:
// Skip this operation if currently locked
if( !locked )
{
lock(); // ka-blam, long timeout inside time-sensitive code
}
But, this is simply dumb coding, and a lock(0) should have been used
instead.
I was hoping for either a .NET API function, or even a Win32 API
function that can take in the internal HANDLE and tell me whether the
current thread owns it or not.
Thankee-sai,
-ken