On 5/30/12 5:43 AM, Regan Heath wrote:
Not in all cases. If you have a synchronized class, say a thread-safe
container, which has a synchronized lookup and synchronized insert
function, code like..
if (!o.lookup(...))
o.insert(...)
obtains and releases the mutex twice each, and in between another thread
could call o.insert() and insert the missing object - resulting in 2
copies being inserted (or a duplicate insert exception being throw,
or....).
Now, the above is bad design, but the only other choice is to expose
lock() and unlock() methods (or the mutex - back to square 1one) to
allow locking around multiple class, but now the caller has to be
careful to call unlock in all code paths. scope helps us in D, but this
is actually the whole point of synchronized blocks - 1. ensuring the
unlock always happens and 2. making the scope of the locking visible in
the code.
There's a hybrid design available - a lock() operation may return a
Locked!Type object which has a richer set of primitives. The implied
understanding is that for the lifetime of that object, the underlying
mutex is locked.
Andrei
