synchronized (this[.classinfo]) in druntime and phobos

Dmitry Olshansky dmitry.olsh at gmail.com
Thu May 31 08:23:29 PDT 2012


On 31.05.2012 19:11, Steven Schveighoffer wrote:
> On Thu, 31 May 2012 10:49:52 -0400, Dmitry Olshansky
> <dmitry.olsh at gmail.com> wrote:
>> OK let me land you a hand here. My proposal, that I think fits your
>> ideas quite favorably.
>
> [snip]
>
>> Does it makes sense?
>
> Everything but the ordering. I like the idea of ordering the locks based
> on an intrinsic value, but opCmp isn't it. Objects can mutate, and opCmp
> may produce different results. Imagine:
>
> synchronized(a, b) // at this point a < b
> {
> a.makeGreaterThan(b);
> assert(a > b);
> }
>

No way! I live in world where victim's hand is cut off as a punishment 
for mutating a lock after creation ;)

> You *never* want the ordering to change.
>
> But I think we can probably work that out. What about comparing handles
> of the mutexes? So you sort based on some property __mutex_id() which
> must return a unique size_t that can be used to always define an
> ordering of locking mutexes? Most mutexes are allocated by the OS, and
> so their handles won't be affected by a moving GC, so you likely will
> use the handle value.
>

This could work. In fact I imagined comparing handles ...
As with math at large you may either project (biject) your domain to a 
well-known one (like numbers, mutex_id in your case) and work with it or 
define all relevant properties for whatever your values in this domain 
are (providing custom ordering for user defined types).



-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list