[dmd-concurrency] synchronized, shared, and regular methods inside the same class
Sean Kelly
sean at invisibleduck.org
Mon Jan 4 21:58:59 PST 2010
I think the thread class should remain in Druntime in some form, and that this new API should live in Phobos. I'd expect the Druntime thread class to see little explicit use, but every once in a while there'll probably be someone that wants to do classic multithreading.
On Jan 4, 2010, at 8:49 PM, Andrei Alexandrescu wrote:
> I think there will be no more Thread class (sorry, Sean :o)). Just before starting this list we were discussing creating a small hierarchy that integrates threads, processes, and remote processes. The basic idea of that hierarchy is, again, that some users should be able to manipulate a concurrent entity without knowing whether it's a thread or a process.
>
> Andrei
>
> Graham St Jack wrote:
>>>>> I'm hoping this library-level trick will be enough to allow most of the classic synchronization mechanisms to be used in D 2.0.
>>>>>
>>>>>> Re synchronized containers - I don't like the idea at all. That is going down the path of having many shared objects, which is notoriously difficult to get right, especially for non-experts. IMO, shared objects should be small in number, and serve as boundaries between threads, which otherwise play in their own separate sand-pits.
>>>>>>
>>>>> A good pathological but functionally correct example is the Thread class in core.thread. Thread instances should really be labeled as shared, but I know that when this happens the compiler will throw a fit. The thing is, while some of the methods are already synchronized, there are quite a few which are not and don't need to be and neither do they need the variables they access to be made lock-free. Even weirder is:
>>>>>
>>>> Well I think Thread is a threading primitive so we shouldn't expect to be implementable without some oddities.
>>>>
>>>
>>> Sounds good. Hopefully, it will be uniquely horrifying.
>>> _______________________________________________
>>>
>> One aspect of the Thread class that I find really annoying is that its name is of type char[] instead of string. Can we change this please? Also, it would be nice to have additional constructors that take a name.
>> I include thread names in my logs, so all my threads have names. This means I have code like this:
>> thread.name = "name".dup;
>> in the constructors of all my active classes, which is nasty.
>> ------------------------------------------------------------------------
>> _______________________________________________
>> dmd-concurrency mailing list
>> dmd-concurrency at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
More information about the dmd-concurrency
mailing list