C.Y.M wrote:
Attached you'll find a suggested fix. It works for me here.
It works for me too! Thank you so much. I have applied this patch
to the latest thread.[ch] and streamdev works like a charm again. :)
Excellent work.
Well, there are still some issues left:
1.) what happens if StartThread() get's never called?
Deadlock at childTidChanged.Wait().
In what situation would StartThread() not be called?
When pthread_create() fails.
2.) what happens if StartThread() returns before the Wait() is reached?
Deadlock at childTidChanged.Wait().
Isnt that what the mutex is for?
Hmm. I thought of the case where StartThread() is very fast and locks
the Mutex, changes childTid, unlocks it, executes Action(), locks the
Mutex, changes childTid again and unlocks the mutex. If then Wait() is
reached, there is a deadlock.
But you are right: moving up the cMutexLock before pthread_create()
should solve this issue, as childTid then cannot be modified before the
Wait() is reached.
So some error checking and an additional variable for indicating
whether StartThread() returned already will be necessary and maybe a
TimedWait(), too.
I've just modified it like that: