[boost] Re: rw_mutex changes

From: Daniel Spangenberg (dsp_at_[hidden])
Date: 2003-10-23 01:47:43

Hello Michael Glassford,

Michael Glassford schrieb:

> Quite some time ago I made some modifications to the rw_mutex and rw_lock
> classes that can now be found in the "thread_dev" branch of Boost.Thread (at
> the time I made the changes, these classes were not in CVS). I corresponded
> privately with William Kempf (author of Boost.Thread but not of these
> classes) about the changes, and he said he would be interested in looking at
> them; however, several high-priority projects came up at work and I was
> never able to finish them. I was able to finish the changes a few months
> ago, but he hasn't responded to any of my messages (I've noticed he hasn't
> been posting recently either), so I thought I would ask here: is there any
> interest in these changes? And, if they turn out to be worthwhile enough,
> what would be the appropriate way of getting them into CVS?
>
> Below is a list of what I did and what remains to be done. I'll be glad to
> make the code itself available in whatever way is most appropriate.
>

First let me thank you again for your tip concerning the current rw_mutex
implementation
in the boost CVS branch as your answer in the thread "read/write mutexes and
boost".

I would strongly encourage to workout further "higher-order" (more complex)
multi-threading idioms in the boost thread library. But there is one question left
concerning
the current implementation of

template<typename Mutex>
struct rw_mutex_impl;

There exists a comment in the header file rw_mutex.hpp, which says:

"Shared implementation construct for explicit Scheduling Policies
This implementation is susceptible to self-deadlock, though...."

What does that mean? Is this limitation based on this very first implementation
or can I conclude from it that it can be shown, that the canonical
multi-reader-single-writer-mutex can not be solved internally dead-lock save
by the nature of this idiom?

Greetings from Bremen,

Daniel