[boost] Re: rw_lock / next thread version

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-07-14 06:54:06

Howard Hinnant wrote:
[...]
> class rw_mutex
> {
> public:
>         typedef detail::read_lock<rw_mutex>  read_lock;
>         typedef detail::write_lock<rw_mutex> write_lock;
>       ...
> };
[...]
> This looks slightly more readable and writable to me.  And will avoid
> unlock() having to check what kind of lock (read or write) it is trying
> to unlock.

Yup. 

http://google.com/groups?threadm=3ef71197%40usenet01.boi.hp.com
(Subject: Re: newbie question)

<quote>

 > And, you know, the fact POSIX threading API doesn't have rdunlock()
 > and wrunlock() operations [separate calls] makes me kinda wonder WHY
 > "someone" was definitely NOT thinking in the direction of reducing
 > the amount of reordering constraints imposed on the implementation
 > [i.e. compiler, in the first place; things like IPA aside] to the
 > absolute minimum that's actually needed when the current threading
 > API was created/voted. You keep telling me about the mutex... think
 > of a read-write lock for a second, please.

 Believe me, I've thought about it for a lot more than a second.

 As for the combined unlock function, all I can say is that I always thought 
 that was a bad idea too. Not just for potential efficiency, but also 
 because it restricts error checking. That is, if someone accidentally calls 
 pthread_rwlock_wrunlock() twice, you can cause it to fail. But readers 
 generally aren't identified, merely counted, so if a writer calls 
 pthread_rwlock_unlock() twice, and on the second call there's one or more 
 readers, the call can do nothing but "successfully" unlock for read. The 
 alternative would be to keep a list of all active readers; but that gets 
 messy quickly when you have to account for a thread possibly holding 
 multiple read locks at the same time.
 
 You can take this as evidence that POSIX doesn't always listen to me. ;-)

</quote>

regards,
alexander.

P.S. Butenhof is, of course totally wrong in the rest of that article. ;-)