Should core.sync.mutex.Mutex, core.sync.condition.Condition, etc. have all their methods be shared?

[Alex Rønne Petersen]

On 18-11-2012 10:58, Dmitry Olshansky wrote:
> 11/18/2012 11:13 AM, Alex Rønne Petersen пишет:
>> On 18-11-2012 05:58, Jonathan M Davis wrote:
>>> On Sunday, November 18, 2012 05:51:00 Alex Rønne Petersen wrote:
>>>> On 18-11-2012 05:46, Jonathan M Davis wrote:
>>>>> I don't know if we can answer this for sure at the moment given the
>>>>> ongoing
>>>>> discussion on shared, but looking at core.sync, it occurred to me that
>>>>> there's a major problem with the classes in there. None of the work
>>>>> with
>>>>> shared. And unless I'm missing something here, I don't see how many of
>>>>> them are even useful as anything other than shared. After all, what
>>>>> good
>>>>> is a mutex which is thread-local? But none of the methods on Mutex
>>>>> or its
>>>>> friends are shared.
>>>>>
>>>>> So, the question is should the all have their methods shared? And if
>>>>> they
>>>>> should, is there any reason to have non-shared overloads for them?
>>>>> What
>>>>> good are they as anything other than shared? How is anyone using them
>>>>> right now?
>>>>>
>>>>> - Jonathan M Davis
>>>>
>>>> Not at this point in time. It would break a ridiculous amount of
>>>> code if
>>>> we did this, given the current extremely annoying nature of shared.
>>>>
>>>> Most D code I have seen in the wild just shares mutexes, conditions,
>>>> etc
>>>> with __gshared or some other mechanism anyway, so I don't think there's
>>>> anything to gain. Like, what would shared actually buy you here?
>>>
>>> __gshared is a good reason for leaving non-shared overloads, but isn't
>>> code
>>> really supposed to be using shared and not __gshared unless it's
>>> specifically
>>> extern(C)? That being the case, I'd expect shared to be the correct
>>> thing to
>>> use with mutexes normally, and right now, that won't work without a
>>> ton of
>>> casting or adding shared overloads.
>>>
>>> - Jonathan M Davis
>>>
>>
>> I don't know what anything that has to do with shared is supposed or not
>> supposed to do. It is not clear, even to the primary language designers,
>> what shared actually is, so I really can't say anything to this...
>>
>
> Let's please stop this mantra. It buy us nothing but FUD.
>
> One thing is clear - shared is not going away over night. Yes, having
> auto-magic atomic ops for various builtins is discussed, the kind of
> memory model is discussed.
>
> Everything else stays. It's the globally shared data and it has tight
> restrictions on what you can do with it. As such it is (just like
> immutable) is safely passable between threads.

There have been proposals to a completely different meaning of shared 
that has nothing to do with memory models or atomic ops. There is no FUD 
here. Shoehorning shared in its current state into core.sync is just 
plain unreasonable given that nothing has been set in stone about the 
meaning of shared at all yet.

>
>> All I can say is, let's wait with this until we know what shared is
>> going to actually do. We don't want to do something we'll regret later.
>
> Obviously we know what shared is. It's just certain details need
> straightening up. And certainly druntime/std.concurrency should add more
> support for it where meaningful.

We don't know at all what shared is. Have you been following the other 
thread? People have wildly different ideas of what it should do.



I don't see why we should be in a hurry to add shared to core.sync in 
particular. Practically all of the runtime and standard library can't 
work properly with shared anyway, so it's not going to change a whole 
lot. I think it's much more sensible to wait until shared's semantics 
are set in stone and *then* start adapting the runtime and standard library.

I can't stop anyone from just doing this, of course, but it seems like a 
premature change to me.

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org