Thread overview | ||||||||
---|---|---|---|---|---|---|---|---|
|
February 27, 2006 Suggestion for Condition variables | ||||
---|---|---|---|---|
| ||||
Here is a suggestion for an extension to D to handle pthread-like condition variables in a way that fits neatly with the "synchronized" keyword. I use threads a lot, and quite often find that I need conditions, but even though all the functionality is there in the locks library, it is galling that I can't use the same mutex as the "synchronized" keyword. The alternatives seem to be to: * Eliminate or ignore the synchronized keyword and use a library all the time. * Make the language "aware" of the library, and provide a way of getting an object's mutex. * Add some more keywords to handle conditions directly. My suggestion is for the last, because I like synchronized, and because I don't like making the language aware of the libraries. So, the suggestion is to add: * A "condition" keyword that behaves for the most part just like a bool data type, but is actually a condition variable. * A "waitfor" keyword. It would be used like: waitfor (condition_name); to wait for the condition to become true, and waitfor (condition_name; timeout_value); to wait for the condition to come true, or the timeout period to expire. Timeout could be ulong nanoseconds, for instance. Here is a simple example with two conditions in a class in fast-and-loose pseudo-code. The two conditions are used to show how simple this arrangement can be compared to trying the same thing in Java, which has a limit of one condition per object. The example Queue class is used to facilitate the transfer of data between two threads - a supplier and a worker. The supplier calls finalize() when it wants the worker to terminate, blocking until all the work has been done. class Queue { bool finalizing; condition ready; condition done; // add an item to the queue - called by a supplier thread synchronized void add(int item) { ...add item to back of a queue... ready = true; } // remove an item from the queue - called by a worker thread synchronized int remove() { waitfor (ready); if (...queue is empty...) { done = true; throw new FinalisedException(); } int item = ...remove item from front of queue... ready = !(...queue is empty...) || finalizing; return item; } // finalize the queue - normally called by the supplier thread synchronized void finalize() { finalizing = true; ready = true; waitfor (done; timeout_value); if (!done) throw new TimeoutException(); } } The compiler can do all the necessary stuff like: * re-evaluating the condition after waking up, and waiting again if the condition has been cleared by a critical race. * making it an error to use conditions outside of synchronized methods. I think this is much tidier than the Java approach, and it is certainly a whole lot easier than using pthread conditions - even through a library. |
February 27, 2006 Re: Suggestion for Condition variables | ||||
---|---|---|---|---|
| ||||
Posted in reply to Graham St Jack | Graham St Jack wrote: > Here is a suggestion for an extension to D to handle pthread-like condition variables in a way that fits neatly with the "synchronized" keyword. > > I use threads a lot, and quite often find that I need conditions, but even though all the functionality is there in the locks library, it is galling that I can't use the same mutex as the "synchronized" keyword. > > The alternatives seem to be to: > * Eliminate or ignore the synchronized keyword and use a library all the time. > * Make the language "aware" of the library, and provide a way of getting an object's mutex. > * Add some more keywords to handle conditions directly. I've been thinking about this as well, and I think it helps that the monitor location is already specified in the ABI. This should allow library use of monitors whether there's any official language support or not. > My suggestion is for the last, because I like synchronized, and because I don't like making the language aware of the libraries. > > > So, the suggestion is to add: > > * A "condition" keyword that behaves for the most part just like a bool data type, but is actually a condition variable. Personally, I'd be happy with library code for this, so long as it could use the built-in monitors. I'd also like a bit more flexibility with how locks are obtained and such, but perhaps this is better left for later. Sean |
February 27, 2006 Re: Suggestion for Condition variables | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | Sean Kelly skrev: > Graham St Jack wrote: >> Here is a suggestion for an extension to D to handle pthread-like condition variables in a way that fits neatly with the "synchronized" keyword. >> >> I use threads a lot, and quite often find that I need conditions, but even though all the functionality is there in the locks library, it is galling that I can't use the same mutex as the "synchronized" keyword. >> >> The alternatives seem to be to: >> * Eliminate or ignore the synchronized keyword and use a library all the time. >> * Make the language "aware" of the library, and provide a way of getting an object's mutex. >> * Add some more keywords to handle conditions directly. > > I've been thinking about this as well, and I think it helps that the monitor location is already specified in the ABI. This should allow library use of monitors whether there's any official language support or not. > >> My suggestion is for the last, because I like synchronized, and because I don't like making the language aware of the libraries. >> >> >> So, the suggestion is to add: >> >> * A "condition" keyword that behaves for the most part just like a bool data type, but is actually a condition variable. > > Personally, I'd be happy with library code for this, so long as it could use the built-in monitors. I'd also like a bit more flexibility with how locks are obtained and such, but perhaps this is better left for later. Any comments on Tommie Gannerts implementation? http://www.digitalmars.com/d/archives/digitalmars/D/31340.html /Oskar |
February 27, 2006 Re: Suggestion for Condition variables | ||||
---|---|---|---|---|
| ||||
Posted in reply to Oskar Linde | Oskar Linde wrote:
>
> Any comments on Tommie Gannerts implementation?
> http://www.digitalmars.com/d/archives/digitalmars/D/31340.html
It does pretty much what I want, but i haven't found the time to play with it yet.
Sean
|
February 27, 2006 Re: Suggestion for Condition variables | ||||
---|---|---|---|---|
| ||||
Posted in reply to Oskar Linde | Oskar Linde wrote:
> Sean Kelly skrev:
>
>> Graham St Jack wrote:
>>
>>> Here is a suggestion for an extension to D to handle pthread-like condition variables in a way that fits neatly with the "synchronized" keyword.
>>>
>>> I use threads a lot, and quite often find that I need conditions, but even though all the functionality is there in the locks library, it is galling that I can't use the same mutex as the "synchronized" keyword.
>>>
>>> The alternatives seem to be to:
>>> * Eliminate or ignore the synchronized keyword and use a library all the time.
>>> * Make the language "aware" of the library, and provide a way of getting an object's mutex.
>>> * Add some more keywords to handle conditions directly.
>>
>>
>> I've been thinking about this as well, and I think it helps that the monitor location is already specified in the ABI. This should allow library use of monitors whether there's any official language support or not.
>>
>>> My suggestion is for the last, because I like synchronized, and because I don't like making the language aware of the libraries.
>>>
>>>
>>> So, the suggestion is to add:
>>>
>>> * A "condition" keyword that behaves for the most part just like a bool data type, but is actually a condition variable.
>>
>>
>> Personally, I'd be happy with library code for this, so long as it could use the built-in monitors. I'd also like a bit more flexibility with how locks are obtained and such, but perhaps this is better left for later.
>
>
> Any comments on Tommie Gannerts implementation?
> http://www.digitalmars.com/d/archives/digitalmars/D/31340.html
>
> /Oskar
The patch neatly implements a fourth option - give a library back-door access to an object's mutex. While I haven't tried it out, it achieves what I need very well.
I do have a preference for an addition to the language because the compiler can spot a few kinds of mistakes for you, but this looks a whole lot more achievable. Surely something like this could be slipped into phobos - maybe even into std.thread.
How come this didn't go further? Lack of support for conditions is a glaring omission from phobos.
|
February 27, 2006 Re: Suggestion for Condition variables | ||||
---|---|---|---|---|
| ||||
Posted in reply to Graham St Jack | Graham St Jack wrote:
>
> How come this didn't go further? Lack of support for conditions is a glaring omission from phobos.
Perhaps simply because it wasn't formally submitted? I couldn't say. I definately plan to add conditions to Ares before too terribly long as I find them indispensable.
sean
|
Copyright © 1999-2021 by the D Language Foundation