On 30 May 2012 17:23, Alex Rønne Petersen <a...@lycus.org> wrote: > On 30-05-2012 18:14, Andrei Alexandrescu wrote: >> >> On 5/30/12 9:03 AM, Regan Heath wrote: >>> >>> On Wed, 30 May 2012 16:46:54 +0100, Andrei Alexandrescu >>> <seewebsiteforem...@erdani.org> wrote: >>> >>>> On 5/30/12 2:34 AM, deadalnix wrote: >>>>> >>>>> Le 29/05/2012 23:33, Andrei Alexandrescu a écrit : >>>>>> >>>>>> 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 >>>>> >>>>> >>>>> I think something similar to range design here is the way to go. >>>>> >>>>> It is easy to define something like >>>>> >>>>> template isLockable(T) { >>>>> enum isLockable = isShared!T && is(typeof(T.init.lock())) && >>>>> is(typeof(T.init.release())); >>>>> } >>>>> >>>>> And allow locking only if(isLockable!Type) . >>>>> >>>>> Now we can create SyncObject or any structure we want. The point is >>>>> that >>>>> we lock explicit stuff. >>>> >>>> >>>> But in this design anyone can lock such an object, which was something >>>> you advocated against. >>> >>> >>> I think there is some confusion here as to what the "problem" is and is >>> not. >>> >>> The problem is /not/ that you can lock any object. >>> The problem is /not/ that we have synchronized(object) {} >>> The problem is /not/ that we have synchronized classes/methods. >> >> >> Several posts in this thread assert that such are problems. >> >>> The problem /is/ that synchronized classes/methods use a mutex which is >>> exposed publicly, and it the same mutex as used by synchronized(object) >>> {}. This exposure/re-use makes deadlocks more likely to happen, and >>> harder to spot. >> >> >> This is news to me. How do you publicly access the mutex of a >> synchronized class object? > > > Generally in two ways: > > 1) synchronized (obj) > 2) obj.__monitor > > (1) accesses it in order to actually do locking, but if obj is an > instantiation of a class that uses the this reference internally for > locking, you end up with potential deadlocks. Therefore, you can say that > obj's mutex is exposed. This isn't necessarily bad, because if obj does > *not* use its this reference for synchronized statements, nothing will blow > up. This is why the OP was about banning synchronized (this). > > (2) is an undocumented feature of the language that druntime (and maybe some > phobos code) makes use of to create/alter/delete monitors. >
I'm pretty certain the use of .__monitor is stricted only to: object_.d - The frontend implementation which contains the underlying functions that are invoked when you synchronise(obj). monitor_.d - The backend implementation which contains the platform separated bits. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';