Asynchronous concurrency with reference types

Peter Alexander peter.alexander.au at gmail.com
Fri Feb 4 15:21:49 PST 2011


On 4/02/11 8:42 PM, spir wrote:
> On 02/04/2011 07:18 PM, Peter Alexander wrote:
>> I would like to be able to spawn a thread, which does a lot of work,
>> and then
>> returns (in some way) the result of its computations to the main
>> thread. I
>> would really like to avoid copying its results if possible.
>>
>> Logically, what I would like is something like this:
>>
>>
>> class LotsOfData { ... }
>>
>> void doStuff(LotsOfData d) { ... }
>>
>> shared(LotsOfData[]) data;
>>
>> void main()
>> {
>> spawn( &doWork );
>> while(true)
>> {
>> foreach (d; data)
>> doStuff(d);
>> }
>> }
>>
>> void doWork()
>> {
>> LotsOfData d = new LotsOfData;
>> // lots of computation on d
>> data ~= d;
>> }
>>
>>
>> Essentially, the work that doWork does needs to be returned to the
>> main thread
>> asynchronously, and obviously in a thread-safe manner.
>>
>> What's the best way to do this? The above won't work because ~= isn't
>> atomic,
>> so you can't do it on shared data.
>
> (I have few exp in the paradigm, so don't believe me.)
>
> It seems your problem is a typical case that cannot be safe as is.
> Essentially, IIUC, you want a shared set of data to be fed (more
> generally: mutated) from a thread, while another thread (here, the main
> one) processes bits of it. How can this be correct as is --except as you
> say if mutating operations were atomic?
> I think in such a case you /must/ have a communication protocal between
> both tasks/threads. It is not due to language features (present ot not,
> this or that way) but to the problem itself. Correct me if I'm wrong,
> please.
>
> Denis

You may be right, I don't know (that's why I'm asking!)

I was hoping that I would be able to do something using synchronized 
classes, but I'm not fully up to speed with how they interact with 
shared and immutable, and all the semantics associated with it. I 
understand that passing immutable value types around is very easy, but 
unfortunately that's rarely practical.

Things might be easier if the error messages associated with D's 
concurrent features weren't especially unhelpful (for example, trying to 
spawn a thread with reference type parameters just gives you a 'no match 
for spawn template' error). It's nice that it stops you from doing such 
things, but it would be nice if it told me why it's not going to let me 
do them.


More information about the Digitalmars-d-learn mailing list