On Wed, 30 May 2012 13:55:10 +0100, Dmitry Olshansky
<dmitry.o...@gmail.com> wrote:
On 30.05.2012 16:43, Regan Heath wrote:
On Wed, 30 May 2012 00:10:19 +0100, Jonathan M Davis
<jmdavisp...@gmx.com> wrote:
On Wednesday, May 30, 2012 01:02:53 Alex Rønne Petersen wrote:
But mutexes allow proper encapsulation by hiding the mutex resource.
As
I've proven in the very OP of this thread, both druntime and phobos
suffer from the anti-pattern that is locking on a public resource when
you shouldn't. The language encourages doing it with this synchronized
business.
From your comments, it sounds to me like the problem is entirely with
synchronized blocks, not sychronized classes. Synchronized classes
don't have
the issue of having externals lock on them without the explicit use of
synchronized blocks. They're the equivalent of locking a mutex in
every public
function and releasing it afterwards. The problem is that that mutex is
effectively public such that when a synchronized block is used on it,
it locks
on the same mutex. If no synchronized blocks are used, as far as I can
tell,
it's a non-issue.
As such, wouldn't simply making the use of a sychronized block on a
synchronized object illegal fix the problem?
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.
synchronized class Container
{
void applyLocked(scope delegate void(Container _this));
...
}
Neat :)
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
