On 30-05-2012 08:23, Sean Kelly wrote:
On May 29, 2012, at 4:07 PM, Andrei Alexandrescu<seewebsiteforem...@erdani.org>
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.
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.
I bet this is because monitors are lazily initialized, so the cost of acquiring
a lock is more than just locking the underlying mutex. The implementation for
built-in monitors really isnt great. I've been meaning to do something about
that.
We also need to fix the monitor memory leak that sometimes manifests
itself...
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
