Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Threading in QB64pe (again)
#12
(05-28-2024, 04:03 PM)justsomeguy Wrote: I would appreciate it if you go into more detail on this. Perhaps some sample code?
I would recommend reading up on stack vs. heap allocation in C and C++. That said the gist is that `thread_data tdata` declares the `thread_data` structure on the stack, that means it only exists while the main thread is in the call to `invokeWorker`. Once `invokeWorker` returns, the thread_data variable goes away and its memory will be reused for something else.

The issue that comes up is that a pointer to the `tdata` variable is passed to `pthread_create()` (as the parameter to the new thread). That starts a separate thread and the original thread can can get the success result from `pthread_create` and then return from `invokeWorker` all before the new thread actually starts running any code. Then you're in the situation where the new thread will be reading from the `tdata` variable while it is already gone from the original thread (and its memory is likely being reused). It's a situation where the issue is probably avoided in this simplified example, but will start to blow up once your code gets more complex and you're calling more functions.

(05-28-2024, 04:03 PM)justsomeguy Wrote:
Quote:3. Because there's no lock protecting access to the images, the main thread could end up reading from the image while a worker thread has only written half a color.
This was by design. Early prototypes had corruption of data across the color bands i.e. Threads were writing to the wrong color band.
Maybe we're talking about the same thing, but I'm talking about the issue that your code writes four bytes (via four _MEMPUT commands) to the image. The main thread may read the image data while you have only written two of the four bytes, displaying an incorrect color as the result. A mutex is used to avoid this kind of issue, you give each image a mutex and then lock/unlock the mutex every time the image is used (so, around the `_MEMPUT`s and the `_PUTIMAGE`). That way the main thread will only read from an image when the corresponding worker thread is not writing to it.
Reply


Messages In This Thread
Threading in QB64pe (again) - by justsomeguy - 05-27-2024, 12:58 AM
RE: Threading in QB64pe (again) - by DSMan195276 - 05-27-2024, 11:53 AM
RE: Threading in QB64pe (again) - by aurel - 05-27-2024, 12:26 PM
RE: Threading in QB64pe (again) - by justsomeguy - 05-27-2024, 02:32 PM
RE: Threading in QB64pe (again) - by DSMan195276 - 05-27-2024, 04:42 PM
RE: Threading in QB64pe (again) - by a740g - 05-27-2024, 06:26 PM
RE: Threading in QB64pe (again) - by DSMan195276 - 05-27-2024, 09:55 PM
RE: Threading in QB64pe (again) - by justsomeguy - 05-28-2024, 01:41 AM
RE: Threading in QB64pe (again) - by DSMan195276 - 05-28-2024, 01:31 PM
RE: Threading in QB64pe (again) - by justsomeguy - 05-28-2024, 04:03 PM
RE: Threading in QB64pe (again) - by Kernelpanic - 05-28-2024, 06:46 PM
RE: Threading in QB64pe (again) - by DSMan195276 - 05-28-2024, 11:14 PM
RE: Threading in QB64pe (again) - by justsomeguy - 05-29-2024, 03:33 PM
RE: Threading in QB64pe (again) - by DSMan195276 - 05-30-2024, 02:13 AM
RE: Threading in QB64pe (again) - by justsomeguy - 05-30-2024, 04:33 AM
RE: Threading in QB64pe (again) - by justsomeguy - 05-31-2024, 03:00 PM
RE: Threading in QB64pe (again) - by SMcNeill - 06-02-2024, 08:14 AM
RE: Threading in QB64pe (again) - by justsomeguy - 06-02-2024, 01:11 PM
RE: Threading in QB64pe (again) - by SMcNeill - 06-02-2024, 04:01 PM



Users browsing this thread: 3 Guest(s)