[boost] Re: Lock unification [move]

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-22 15:03:41

Howard Hinnant wrote:
> On Jul 22, 2004, at 9:41 AM, Michael Glassford wrote:
> 
>>> I agree 100%, though I've spelled deferred_t as defer_lock_type and 
>>> added try_lock_type.  Thanks.  You can now:
>>> scoped_lock lk1(m, defer_lock);  // not locked
>>> scoped_lock lk2(m, try_lock);    // tries to lock
>>
>>
>> If you remember, I proposed something along these lines (at the 
>> suggestion of Vladimir, IIRC) and liked it a lot, but changed my mind 
>> when it was pointed out that it prevents making the choice at run time 
>> whether the lock should be locked or not. With movable locks, as you 
>> point out below, this is changed somewhat.
> 
> 
> Sorry, my acknowledgment list has gotten so confused I didn't even 
> attempt one in the latest spec.  The thread has gotten so long I'm 
> forgetting who's proposed what, and have not taken the time to read back 
> and check.

I'm not worried about that; I've forgotten who said what myself. I just
wondered if you remembered that it had come up before. For what it's
worth, I believe my final proposal looked as follows (the items marked
"-" are possible constructors that I intentionally rejected):

ScopedLock
----------
     lock(m)
     lock(m, unlocked)

-   lock(m, locked)
-   lock(m, locked, blocking)
-   lock(m, blocking)

ScopedTryLock
-------------
-   try_lock(m) //locked, blocking
     try_lock(m, unlocked)
     try_lock(m, blocking)
     try_lock(m, non_blocking)

-   try_lock(m, locked, blocking)
-   try_lock(m, locked, non_blocking)

ScopedTimedLock
---------------
-   timed_lock(m) //locked, blocking
     timed_lock(m, unlocked)
     timed_lock(m, blocking)
     timed_lock(m, non_blocking)
     timed_lock(m, t)

-   timed_lock(m, locked, blocking)
-   timed_lock(m, locked, non_blocking)
-   timed_lock(m, t, locked)
-   timed_lock(m, t, locked, blocking)
-   timed_lock(m, t, blocking)

>>> I've gone with:
>>> mutex_type* mutex() const;
>>> I don't have very strong feelings on this one, except that the 
>>> current boost design does not hide the mutex interface as we thought 
>>> it should.  You just get to the mutex interface via the lock instead 
>>> of directly.  So I'm not that anxious to make it difficult to access 
>>> the mutex and operate on it directly.  Sometimes there's good reason 
>>> to do that.
>>
>>
>> What can you do to a mutex except lock it with a lock object?
> 
> 
> My comments were based on the fact that currently the mutex interface is 
> private except for construction and destruction.  This is meant to 
> encourage the programmer to use the mutex only in an orderly (RAII) 
> fashion.
> 
> <soapbox>
> However we do not currently prohibit code such as the following:
> 
> typedef mutex::scoped_lock MyMutex;
> mutex m;
> MyMutex my_mut(m, false);
> 
> void foo()
> {
>     my_mut.lock();
> }
> 
> void bar()
> {
>     my_mut.unlock();
> }
> 
> int main()
> {
>     foo();
>     bar();
> }

No, but the lock still unlocks when it goes out of scope and the mutex 
doesn't, which is some difference.

Do you know of a way to prohibit such code?

> I.e. It is not difficult to make a lock look exactly like a mutex with 
> public member functions, and then use it in whatever way (orderly or 
> not) you want to.  Given that, perhaps it is better to just make the 
> mutex interface public in the first place, 

I don't agree.

 > and expose the mutex of a
> lock.  Afterall, there are legitimate uses for locking and unlocking a 
> mutex in a non-RAII pattern, and there are legitimate uses for needing 
> access to a lock's mutex.  The tools should not get in the way of the 
> coder in the name of trying to save the coder from his own stupidity.  
> Otoh, a good tool will make it easy to avoid stupid mistakes and write 
> correct, efficient and elegant code.  It is always a delicate line to 
> walk when designing an interface.
> </soapbox>
> 
>> Another possibility is to name the second parameter as an adjective 
>> describing the initial state of the lock instead of a verb:
>>
>> scoped_lock l(m, unlocked);
> 
> 
> scoped_lock l(m, tried);  // ?
> scoped_lock l(m, Heisenberg);  // ? :-)

scoped_lock l(m, non_blocking);

Mike