On 30-05-2012 01:07, Andrei Alexandrescu wrote:
On 5/29/12 3:58 PM, Alex Rønne Petersen wrote:
On 30-05-2012 00:45, Andrei Alexandrescu wrote:
On 5/29/12 2:57 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:33, Andrei Alexandrescu wrote:
On 5/29/12 1:37 AM, deadalnix wrote:
I would say that breaking things here, with the right deprecation
process, is the way to go.
So what should we use for mutex-based synchronization if we deprecate
synchronized classes?
Andrei
core.sync.mutex
That's worse.
Andrei
I don't agree.
One simple thing to understand is that core.sync.mutex does everything
synchronized objects do, in a much less structured way. So it's tenuous
to build an argument that synchronized classes do something wrong but
bare, unstructured mutexes do something good.
Okay, let's get something straight here: The Mutex class in
core.sync.mutex is *not* final. It does *not* force you to use it in a
compositional fashion. You can inherit it just as any other non-final
class. And when you use synchronized (mtx), where mtx is an instance of
Mutex or a derived class, it will even do the Right Thing (TM) and lock
on the mutex.
Mutex is effectively the synchronized object type that you want. Why not
just use it?
Also, it is faster than object monitors. This was proven
by David Simcha recently where he sped up GC allocations by some 40%-ish
factor just by changing to a final class derived from core.sync.mutex.
And no, that's not a bug in the monitor implementation. It's a
limitation of the design.
We'd need to take a look at that. I recall at a point Bartosz was
working on cheap locks using the mutex word as a spin lock in certain
circumstances. Anyhow, it's something that would be interesting to look at.
Andrei
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
