[boost] Re: Boost.Threads proposed change: lock constructors

From: Christopher Currie (codemonkey_at_[hidden])
Date: 2004-06-29 07:44:54

Michael Glassford wrote:

 > Christopher Currie wrote:
 >> TryLock: What would be the semantics of l(m, NO_LOCK, b)? In other
 >> words, if you're not going to lock on construction, why specify a
 >> blocking policy?
 >
 >
 > The only reason is so that if you write l(m, LOCK, ...) you could also
 > specify the blocking parameter. An expansion of Vladimir Batov's of
 > using structs rather than enums could help here:
 >
 > struct nolock_t {};
 > nolock_t nolock;
 >
 > struct lock_t {};
 > lock_t lock;
 >
 > class TryLock
 > {
 > TryLock(TryMutex m, no_lock_t s)
 > {...}
 >
 > TryLock(TryMutex m, lock_t s, blocking_t b)
 > {...}
 > }

An interesting syntax, I can see how it does make explicit whether you 
are locking or not. Personally, I dislike having to type an extra 
argument when it's the only choice; IMO if you're specifying a blocking 
parameter, the locking is implied, and therefore superfluous. I was 
thinking something like (going back to enums for a moment):

enum { unlocked = 0, locked } lock_init;
enum { nonblocking = 0, blocking } blocking_action;

class TryLock
{
public:
   TryLock( TryMutex m, lock_init s = locked ) { ... }

   TryLock( TryMutex m, blocking_action b ) { ... }
};

Also, going back to the struct technique, do the struct instances need 
to be in an anonymous namespace to prevent ODR violations? Just trying 
to get my head around the concept.

Christopher

-- 
Christopher Currie <codemonkey_at_[hidden]>