Something needs to happen with shared, and soon.

Manu turkeyman at gmail.com
Thu Nov 15 02:52:05 PST 2012


On 15 November 2012 12:14, Jacob Carlborg <doob at me.com> wrote:

> On 2012-11-15 10:22, Manu wrote:
>
>  Not to repeat my prev post... but in reply to Walter's take on it, it
>> would be interesting if 'shared' just added implicit lock()/unlock()
>> methods to do the mutex acquisition and then remove the cast
>> requirement, but have the language runtime assert that the object is
>> locked whenever it is accessed (this guarantees the safety in a more
>> useful way, the casts are really annying). I can't imagine a simpler and
>> more immediately useful solution.
>>
>
> How about implementing a library function, something like this:
>
> shared int i;
>
> lock(i, (x) {
>     // operate on x
> });
>
> * "lock" will acquire a lock
> * Cast away shared for "i"
> * Call the delegate with the now plain "int"
> * Release the lock
>
> http://pastebin.com/tfQ12nJB


Interesting concept. Nice idea, could certainly be useful, but it doesn't
address the problem as directly as my suggestion.
There are still many problem situations, for instance, any time a template
is involved. The template doesn't know to do that internally, but under my
proposal, you lock it prior to the workload, and then the template works as
expected. Templates won't just break and fail whenever shared is involved,
because assignments would be legal. They'll just assert that the thing is
locked at the time, which is the programmers responsibility to ensure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121115/293f20c2/attachment.html>


More information about the Digitalmars-d mailing list