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