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

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-29 10:39:12

Christopher Currie wrote:
> 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. 

That was an oversight on my part. Though in the case of read/write 
locks, you do need to specify both the lock type (read/write) and 
whether it is blocking or not.

 >  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.

Probably they should be in a separate namespace, though possibly not 
anonymous.

Mike