|
Boost : |
From: Milutin Jovanovic (miki_at_[hidden])
Date: 2000-08-08 15:54:51
From: "Dietmar Kuehl" <dietmar_kuehl_at_[hidden]>
> Sure. But using the 'Lock()' method, a lock can be acquired which is
> not automatically released. This is what I'm opposed to! It is an error
> to hold a lock longer than for a very local scope. With a requirement
> for manual unlocking, you will definitely get into trouble if
> exceptions enter the picture. Thus, I would remove all methods which
> lock a mutex without also ensuring that it is unlocked later. The only
> way to lock a mutex would be through creation of an object which
> releases the lock if it goes out of scope.
First there are legitimate uses of long locks, so you should not try to stop
such usage. If you are worried with exceptions, a simple catch(...) clause
will allow to catch any exception, release mutexes and re-throw. Finally,
what stops the user from dynamically allocating the 'auto_lock' object?
Nothing. So he will still be able to lock for extended periods of time.
This is not to say that locks should be used indiscriminately. Proper thread
synchronisation takes extreme discipline. My view is however that education
is the only way to achieve this.
Cheers,
Miki Jovanovic.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk