[boost] Re: Lock unification [was: Boost.Threads: Do we need all those mutexes?]

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-15 17:09:31

Howard Hinnant wrote:

> On Jul 15, 2004, at 2:58 PM, Michael Glassford wrote:
> 
>> My original intent was to add constructors that
>> would make it explicit whether you were asking for a blocking lock, a
>> try lock, or a timed lock, and to remove the ambiguity in the try_lock
>> constructors (rather arbitrarily, one is blocking, the other
>> non-blocking, even though they look just like the lock class
>> constructors which both block). There were some who argued against my
>> idea and none who supported it, so I dropped the it.
> 
> 
> Fwiw, I'm still toying with:
> 
> lock(m, not_locked);
> lock(m, not_blocked);
> 
> (or whatever the spelling was).  I haven't been using that syntax in my 
> examples simply because I don't have it coded that way and I try to 
> compile my example code before I post it (at least usually).  Anyway, 
> I'm personally not ready to drop the enum set you proposed, or at least 
> a subset of it.

OK, thanks for the feedback.

For what it's worth, then, the latest form of the proposal (which I'm 
not sure I ever posted) looked like this:

namespace lock_state {
     typedef enum
     {
         unlocked=0,
         locked=1
     } lock_state;
} //namespace lock_state

namespace blocking_mode {
     typedef enum
     {
         non_blocking=0,
         blocking=1
     } blocking_mode;
} //namespace blocking_mode

ScopedLock / ScopedReadLock / ScopedWriteLock
---------------------------------------------
     lock(M) //always locking, blocking
     lock(M, lock_state) //blocking

ScopedTryLock / ScopedTryReadLock / ScopedTryWriteLock
------------------------------------------------------
     try_lock(M) //always locking, BLOCKING
     try_lock(M, lock_state) //BLOCKING

     try_lock(M, blocking_mode) //always locking

ScopedTimedLock / ScopedTimedReadLock / ScopedTimedWriteLock
------------------------------------------------------------
     timed_lock(M) //always locking, blocking
     timed_lock(M, lock_state) //blocking

     timed_lock(M, blocking_mode) //always locking

     timed_lock(M, t) //always locking, blocking for time t

> There's a lot of stuff that's been proposed.  Perhaps we need competing 
> implementations that can be played with (as opposed to just competing 
> designs).

Mike