|
Boost : |
From: Jeremy Siek (jsiek_at_[hidden])
Date: 2001-07-17 14:05:45
On Tue, 17 Jul 2001 williamkempf_at_[hidden] 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.
> > 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.
> > 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.
> > 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 ;)
Thanks for the answers!
Jeremy
----------------------------------------------------------------------
Jeremy Siek www: http://www.lsc.nd.edu/~jsiek/
Ph.D. Candidate, IU B'ton email: jsiek_at_[hidden]
Summer Manager, AT&T Research phone: (973) 360-8185
----------------------------------------------------------------------
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk