|
Boost : |
From: Jon Biggar (jon_at_[hidden])
Date: 2003-07-19 13:19:28
Russell Hind wrote:
>>> Ok, but what happens if locking an already locked mutex where
>>> undefined behaviour? This isn't this the same as the smart_ptr
>>> case? Who knows how the actual implementation is on all the
>>> platforms, or future platforms?
>>
>> Um, wasn't the question throw vs assert? In either case we would
>> detect the attempt to relock the lock and not do that.
>>
> Yes it was, you wrote that smart_ptr asserted because that was better
> than dereferencing a null ptr so my question/point is why throw rather
> than assert because locking an already locked mutex (as Peter pointed
> out) is undefined behaviour. Similar results in the end so why assert
> in one and throw in the other? Why not throw in shared_ptr then?
Because there's a difference you don't see. The assert in smart_ptr is
merely replacing one crash (or memory corruption) with an immediate
crash that is easier to debug. In neither case would the program get a
chance to recover or clean up.
In the thread lock case, the throw avoids the undefined behavior
entirely, since it doesn't ever do the underlying OS lock action that
causes the undefined behavior.
-- Jon Biggar Floorboard Software jon_at_[hidden] jon_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk