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