Re: Boost.Threads - Questions on Usage

From: williamkempf_at_[hidden]
Date: 2001-07-17 14:49:35

--- In boost_at_y..., Jeremy Siek <jsiek_at_r...> wrote:
> On Tue, 17 Jul 2001 williamkempf_at_h... wrote:
> >
> > The following works, just to clarify what I said with code:
> >
> > class X {
> > public:
> >    mutable mutex mtx;
> >    int a;
> >    X() : a(0) { }
> >    X(const X& other) { mutex::lock(other.mtx); a = other.a; }
> >    ~X() { }
> > };
> >
> > X x1;
> > X x2(x1);
> >
> > This is the only valid way to copy a "monitor", and making the 
mutex
> > copyable won't make the syntax any easier even if we can get safe
> > copy semantics.
> 
> Ok, I'm happy with the above syntax. I'd recommend changing the
> monitor/buffer example to use the above syntax. We should probably 
never
> use examples that show inheritance from a mutex, it just doesn't 
work in
> too many situations.

I'm not so sure about that.  Most objects that are shared objects are 
not going to need copyable semantics.  The buffer is a classic 
example.  It should be a noncopyable design.  In that case there's no 
reason to not use inheritance.  I totally agree that the example I 
gave needs to be placed in the FAQ so that proper usage is well 
defined for the case where copyable semantics are needed, but I don't 
think we need to go as far as you suggest here.

> > > So exactly what MT behaviour are you refering to?
> >
> > When you copy a mutex as you've tried to do above it leads to
> > deadlock situations since the mutex state is now applied to two
> > distinct sets of data.
> 
> That's your straw man. I never meant to talk about two monitors 
ending up
> with a shared mutex.

I take a little offense at your use of the term "straw man".  What I 
said here is valid, unless you care to show me otherwise.
 
> > > Perhaps there is a way to work around the bad behavoir while 
keeping
> > > copyable.
> >
> > If you can define a method that's safe, I'll reconsider the 
design.
> > However, this was fully discussed a year ago and everyone 
(yourself
> > included, if I recall correctly) agreed that copyable semantics 
were
> > wrong in this case.
> 
> But a year ago I wasn't writing code that used boost::thread :)
> 
> I think it would be possible to define a safe semantics but now I 
don't
> think it is worth it given your copy constructor code.

The only valid copy semantics (that I can see) would be the same ones 
given in the monitor example.  In other words, no copying of state 
what so ever.  Obviously that would be a bad design :).

> > > P.S. The reason I'm pushing on this is that the usage pattern 
I'm
> > looking
> > > at is a very common case, perhaps the most common case following
> > using a
> > > mutex in a simple scope.
> >
> > And the code I gave above won't work for your specific case?
> 
> You code does work for my case... you just hadn't posted it yet ;)

*chuckles*  Well, I did explain it.  You even came very close to 
understanding my explanation when you countered with the copy c-tor 
that did a "new mutex".  There was just a disconnect (probably my 
fault) between the description and the resultant implementation.
 
> Thanks for the answers!

Sure :).

Bill Kempf