D threading and shared variables

Doc Andrew x at x.com
Sun Apr 7 14:35:24 UTC 2019


On Sunday, 7 April 2019 at 14:08:07 UTC, Archie Allison wrote:
> I have written an industrial control program which uses serial 
> ports to communicate with hardware but am having problems, 
> perhaps with shared memory, on Windows.
>
> The SerialPort class calls C object-file functions. Transmits 
> are on one thread and receives on another (all within a class 
> derived from Thread), with a signal(created from a mutex) 
> notifying the transmit thread when a packet has arrived.
>
> This generally works OK when tied to a Console but when link 
> options are changed to be SUBSYSTEM:WINDOWS and 
> ENTRY:mainCRTStartup it rarely does.
>
> Compiling with -vtls shows the serial port is in thread local 
> storage. As a hardware resource, I wasn't sure if this matters. 
> I've tried casting to a shared object so it no longer appears 
> in the -vtls list, with no difference.
>
> Does anyone have ideas about where I may have misunderstood the 
> threading and shared-memory design of D or what I can look at?

When you say it "rarely works" when run as a GUI app (vs 
console), it makes me think that there's probably a race 
condition going on, and the extra context switching that takes 
place in GUI mode makes it more likely. I haven't tried it in D, 
but you may be able use Application Verifier with your app to add 
checks for lock contention. Without more information about the 
way your threads are synchronized it's hard to say for sure 
though.


More information about the Digitalmars-d-learn mailing list