Optional monitors suggestion

[Steven Schveighoffer via Digitalmars-d]

On Mon, 08 Sep 2014 12:57:13 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 9/8/14, 2:10 AM, Andrej Mitrovic wrote:
>> On Thursday, 22 May 2014 at 17:25:30 UTC, Steven Schveighoffer wrote:
>>> A possible path is to introduce the change, but put @monitor on
>>> Object. This will allow all current code to compile as-is.
>>>
>>> Then users who are concerned about their code being affected would be
>>> able to remove @monitor from Object, recompile druntime and phobos
>>> (once we make it work) and allow people to see how their code breaks
>>> without being left hanging (the shipping compiler would still have
>>> @monitor).
>>>
>>> Then eventually, we can remove @monitor from Object, and users who
>>> still wish to force @monitor on Object can do so (recompile druntime
>>> and phobos with @monitor added).
>>
>> This sounds like a reasonable deprecation stage.
>>
>> Anyway it seems like we're all mostly on the same page here (remove the
>> monitor) except the final part: potential implicit performance penalty
>> vs code breakage after a deprecation stage. Either way we chose there's
>> a pull ready[1] that's going stale.

Wow, thanks for waiting until I had some breathing time to look at D to  
bring this up again ;)

I think the implicit performance penalty is not hard to fix.

First, you can flag such uses "You know, you are synchronizing on a  
non- at monitor object, this will be expensive, may want to put @monitor on  
that bad boy" with a tool/compiler.

Second, the number of *classes* upon which one uses synchronization is  
very very small. I anticipate, you will have to put @monitor on 1-2 types  
in your hierarchy, and then everything works beautifully.

>>
>> Can we get an update from both Andrei & Walter to get going with this?
>>
>> [1]: https://github.com/D-Programming-Language/dmd/pull/3547
>
> I'm in favor of getting rid of the monitor field. I'm not sure I  
> understand whether @monitor introduces a field or just an entry in the  
> hashtable. FWIW we could do this for backward compatibility: objects  
> without @monitor use the hashtable, and those with @monitor use a field.

@monitor means to do exactly what the compiler does now. Essentially,  
@monitor tags any class and its derivatives with the existing behavior  
(and flags the TypeInfo as such I think). Without @monitor, you have the  
new behavior which has no monitor, but uses the global hashtable if you  
happen to synchronize with it.

-Steve