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.
