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