Threading in QB64pe (again)

[DSMan195276]

It looks like worked around this problem by adding a 1 second sleep timer after starting the thread. This gave time for the thread to spool up.

In this latest version, it checks if the thread is started before 'invokeWorker' returns. 'invokeWorker' is now a function that returns a success or fail based on if the thread started. Now the threads start a lot faster.

I double check if the arguments going to the worker by recording the 'id' to its UDT. I then print that result above each worker. So far they have all been aligned. 

I have been reading and I'm seeing a few examples of using malloc to pass arguments to the thread. I'm pondering the easiest and simplest way to implement it.

I would look into using a condition variable rather than a busy wait, but overall your approach is fine and should work.

I would like to point out a bit of a nasty issue when using threading in C++ (and many other languages) - the compiler is free to reorganize your code as long as it works the same in a single threaded view. The result here is that the C++ compiler could place your `threadRunning[id] = true;` line before the ` int id = tdata->id;` line, defeating the protection you're attempting. The compiler is not allowed to reorganize such code around mutex lock/unlock or condition variable statements though, so they offer protection against that. It's very unlikely to cause a noticeable issue here, but figured I'd point the issue out, it's one reason why using the provided synchronization primitives like mutexes and condition variables can be important.

I did as you suggested. I hope I implemented it right. I did notice a bit of a slowdown. I suspect its a race condition that I won't have much control over.

Thank you for your suggestions and keep them coming.

Yep, that looks pretty good. One thing is that I wouldn't call `initLock` inside of the worker sub, just call it before you call `pthread_create()`. The risk here is that the lock is not yet initialized when the main thread attempts to take it the first time.

The slowdown is expected, what you're seeing is more or less the situation I was taking about - the main thread was reading while the `_MEMPUT` commands were happening. Now with a mutex in place, instead of both threads reading/writing at the same time, they have to take turns, and that does slow things down when one thread has to wait for the other to finish.

I will say, a mutex is a bit "heavy" for this case since the writing can happen very often. The lock/unlock operations on a mutex aren't super expensive, but also aren't free, if the worker thread has no delay then it might spend the majority of its time just on locking/unlocking the mutex. That in turn leads to more conflicts with the main thread since the mutex spends a lot of its time locked by the worker thread. There's strategies you can use to reduce the amount of locking/unlocking you actually have to do Ex. batch operations together, or use a rotating list of images to avoid so much locking, etc. and that would get you closer to the previous speed with no locking at all.