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.
