I already know this limitations. My app is a single .exe, so I guess it is a single process running multiple threads, some of them needing synchronisation.
One thread iterating through a list of commands and some commands using a thread for carrying out their work. it turns out, that the synchronisation fails. Adding a ‘sleep’ function as a quick and dirty test helps out.
Using the printf turns out, that the mutex ist taken twice, so no synchronisation.
But … the thread iterating through a command list is written in vb.net, calling some functions of a C++ dll and the working thread is written in C++ and part of this dll. I still tought, that I have a single process using multiple threads.
I also guess, that the instructions within a thread were executed in sequence, but different threads were running eventually on different cores, and sync by mutex still does the job.
I will try to use a critical section instead of the mutex, but today my daughter marries …
The job to be done:
Two threads writing into one file. To maintain the correct sequence of write operations I need mutual exclusive access to the file handle. One thread is vb.net code (eg. managed) the other is plain C++ (unmanaged).
At the end of the command list the file is closed before the last Infos were written, so the call to 'fwrite( … ); hangs and the system crashes.
Inserting a ‘sleep’ before closing the file helps out.
With best regards