Pointer across threads
Chris via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Tue Nov 4 06:36:17 PST 2014
On Tuesday, 4 November 2014 at 14:01:16 UTC, anonymous wrote:
> On Tuesday, 4 November 2014 at 12:47:11 UTC, Chris wrote:
>> The following
>>
>> struct DATA {
>> short* data;
>> size_t len;
>> }
>>
>> // data and len are provided by a C function
>> // ...
>> auto data = mymodule.getSpeechData();
>> // cast to immutable, because of concurrency
>> immutable short* tmp = cast(immutable)(data.data);
>> auto proc = spawn(&processData, thisTid);
>> send(processData, tmp, data.len);
>>
>> However, processData never receives "tmp". Is this because tmp
>> and data.data are still pointing to the same address? If this
>> is the case, why doesn't the compiler warn me? Or is it
>> something else (pointer not visible across threads?).
>>
>> Is there a work around? (I wanted to avoid having to convert
>> short* to short[] and .idup it.)
>
> Please provide complete test cases. It makes it way easier for
> others to help.
>
> One thing I noticed is that receiving immutable(short*) doesn't
> work. Instead, it has to be immutable(short)* on the receiving
> end. This is because immutable(T*) is automatically converted to
> immutable(T)* on function calls. And apparently receive's
> matching mechanism is inconveniently literal.
Ah, thanks a lot, that was it! It has to be immutable(short)* on
the receiving end, now it works.
receive (
(immutable(short)* data, size_t len) {
//...
});
It is indeed inconveniently literal, but I guess there's a reason
for it.
I'm still curious, though, how D handles this internally, because
data.data is still mutable while the other reference to the same
address (tmp) is not. What if I change data.data while the other
thread is being executed?
PS In this case, it was hard to provide a complete test case,
because there are things going on in a C function and other D
modules.
More information about the Digitalmars-d-learn
mailing list