Dear Team,
I am running WEC2013 on a iMX7 D and porting my app from another SoC (not Toradex). During testing I running into some issues. Lastly it turns out, that I can take the same mutex from different threads twice, which fools my synchronisation.
Is there any known issue with mutex & Co?
Is there a fix and how can I get it?
I am quite sure, that I use the mutex in the correct way and I used printf to document the end of WaitForSingleObject and ReleaseMutex calls.
We are not aware of any problem about mutexes in the iMX7 BSP. There are a few general limitations on using various synchronization objects. Microsoft explains them in their documentation pages, for example the article about Mutex Objects.
Critical sections only work within a single process
To use mutexes across processes, you typically use a named mutex. For unnamed mutexes you can use the DuplicateHandle() function.
Another general hint: When an application was written for a single-core machine, programmers often take the assumption, that all operations are executed sequentially. This can cause troubles on a multi-core machine, when execution happens truely parallel. For a test, you can try to disable the second core by setting pex.mpenable=0 in the module’s config block.
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).
The fact:
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.
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).
The fact:
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.
