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. ;-)
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
