Threading in QB64pe (again)

[justsomeguy]

Hello all,

I've been revisiting my earlier attempt at threading in QB64pe. You can look at the old thread at https://qb64forum.alephc.xyz/index.php?topic=3865.0 Thanks to guys that responded to that thread and helped me. 

I'm happy to say I made a bit of progress. I managed to get two separate free running threads to run concurrent with my main QB64 program. They don't do much, but they show its possible.

In order to get it working I had to cheat and use a c header file to make a wrapper for pthreads. This makes the declarations easier.

Code: (Select All)

// pthreadGFXTest.h
// Threading Header
#include "pthread.h"
// Only needed for the SIGTERM Constant
#include <signal.h>
// Initialize Threads
pthread_t thread0;
pthread_t thread1;
// Easy way to determine if a thread is running
bool threadRunning0 = false;
bool threadRunning1 = false;
// Setup Mutexes for each of the threads.
static pthread_mutex_t mutex0;
static pthread_mutex_t mutex1;
// QB's names for the threaded Subs
// You can locate these in your ''qb64pe/internal/temp'' folder.
// I found these in the 'main.txt'
void SUB_LINES();
void SUB_CIRCLES();
// wrap the subs so that you can easily get the void* for pthread
void* RunLines(void *arg){
    SUB_LINES();
}
void* RunCircles(void *arg){
    SUB_CIRCLES();
}
// These are the commands that are accessed by you program
void invokeLines(){
    if (!threadRunning0) {
        int iret = pthread_create( &thread0, NULL, RunLines, NULL);
        pthread_mutex_init(&mutex0, NULL);
        threadRunning0 = true;
    }
}
void invokeCircles(){
    if (!threadRunning1) {
        int iret = pthread_create( &thread1, NULL, RunCircles, NULL);
        pthread_mutex_init(&mutex1, NULL);
        threadRunning1 = true;
    }
}
void joinThread0(){
    pthread_join(thread0,NULL);
    threadRunning0 = false;
}
void joinThread1(){
    pthread_join(thread1,NULL);
    threadRunning1 = false;
}
void exitThread(){
    pthread_exit(NULL);
}
void killThread0(){
    if (threadRunning0) {
        int iret = pthread_kill(thread0, SIGTERM);
    }
}
void killThread1(){
    if (threadRunning1) {
        int iret = pthread_kill(thread1, SIGTERM);
    }
}
void lockThread0(){
    pthread_mutex_lock(&mutex0);
}
void unlockThread0(){
    pthread_mutex_unlock(&mutex0);
}
void lockThread1(){
    pthread_mutex_lock(&mutex1);
}
void unlockThread1(){
    pthread_mutex_unlock(&mutex1);
}

The test program draws lines in one thread and circles in another thread. You start and stop the threads by pressing '1' and '2' and 'ESC' quits.

Code: (Select All)

'***********************************************************************************
' Proof of concept threading in QB64pe.
' by justsomeguy
'***********************************************************************************
 
' Thread Library Declaration
DECLARE LIBRARY "./pthreadGFXTest"
  SUB invokeLines ' start Lines thread
  SUB invokeCircles ' start Circles thread
  SUB joinThread0 ' wait til thread is finished
  SUB joinThread1 ' wait til thread is finished
  SUB exitThread ' must be called as thread exits
  SUB killThread0 ' kill the thread
  SUB killThread1 ' kill the thread
  SUB lockThread0 ' mutex lock
  SUB unlockThread0 ' mutex unlock
  SUB lockThread1 ' mutex lock
  SUB unlockThread1 ' mutex unlock
END DECLARE
 
' Global variables
DIM SHARED AS INTEGER q0, q1 ' quit signals
DIM AS STRING ky
 
' Setup screen
_TITLE "Thread test"
SCREEN _NEWIMAGE(1024, 768, 32)
_FONT 8
CLS
 
' Fire up freerunning threads
invokeCircles
invokeLines
 
' Campout in an infinite loop
DO
  ky = INKEY$
  LOCATE 1, 1
  PRINT "Lines are drawn on one thread, Circles are drawn in a second thread."
  PRINT "Press '1' to toggle the Line drawing thread. "
  PRINT "Press '2' to toggle the Circle drawing thread."
  PRINT "Press 'ESC' to exit."
 
  IF ky = "1" THEN
    q0 = NOT q0
    IF q0 THEN
      joinThread0
    ELSE
      invokeLines
    END IF
  END IF
 
  IF ky = "2" THEN
    q1 = NOT q1
    IF q1 THEN
      joinThread1
    ELSE
      invokeCircles
    END IF
  END IF
 
  ' Quit the whole program
  IF ky = CHR$(27) THEN q0 = -1: q1 = -1: joinThread0: joinThread1: SYSTEM
LOOP
 
 
'***********************************************************************************
' Threaded
'***********************************************************************************
 
SUB lines ()
  ' Free running loop
  DO
    ' lock a mutex, just to be safe
    lockThread0
    ' Do something
    LINE (RND * _WIDTH, RND * _HEIGHT)-(RND * _WIDTH, RND * _HEIGHT), _RGB32(RND * 255, RND * 255, RND * 255)
    ' unlock mutex
    unlockThread0
    ' do I need to jump out?
  LOOP UNTIL q0 = -1
  ' Must call exitThread when leaving, so that joinThread works.
  exitThread
END SUB
 
SUB circles ()
  ' Free running loop
  DO
    ' lock a mutex, just to be safe
    lockThread1
    ' Do something
    CIRCLE (RND * _WIDTH, RND * _HEIGHT), RND * 50, _RGB32(RND * 255, RND * 255, RND * 255)
    ' unlock mutex
    unlockThread1
    ' do I need to jump out?
  LOOP UNTIL q1 = -1
  ' Must call exitThread when leaving, so that joinThread works.
  exitThread
END SUB
 

My goal, is to get my 2d physics engine to reside in a separate thread and have it free running computing collisions and motion while the main thread handles I/O and other logic.

I'm using QB64pe 3.11.0. I tested this on Linux Mint, MacOS and Windows 10. On windows I had to add '-pthread' to compiler settings and '--static' to the linker settings.



To get this running on your computer, copy the header to your favorite text editor and save the file under 'pthreadGFXTest.h' Then copy the source to the same directory as the header and make sure your compiler and linker settings are correct. I'm not sure if its necessary, but I save my EXE to the source folder.

Beware that if you decide try playing around with the code, that it could crash in some wild ways. Error messages will not make sense, and it might run a bit and lockup for unknown reasons. QB64pe is not meant to be run like this, so there will not be much help if you try.

[DSMan195276]

This is a nice little demo, but I would caution you that the QB64 runtime is designed around the QB64 code only running on a single thread. It _will_ blow up if you attempt to do anything non-trivial, there's nothing you can do about it. Feel free to still play around with this, but I just want to be honest with you before you spend more time on this, practically speaking this is a dead-end.

[aurel]

I am not sure how your way work for you and don't have time to investigate
but on Windows is a way to use win api call ..like is explained on this site

https://aljensencprogramming.wordpress.c...win32-api/

I just tried this threading once in freeBasic and i was not happy with results.

[justsomeguy]

I would caution you that the QB64 runtime is designed around the QB64 code only running on a single thread. It _will_ blow up if you attempt to do anything non-trivial, there's nothing you can do about it. Feel free to still play around with this, but I just want to be honest with you before you spend more time on this, practically speaking this is a dead-end.

I'm very well aware that QB64 is not designed for this. I stated this in the last paragraph. In my numerous failed attempts, I'm beginning to learn where the boundaries are. Once, I understand the boundaries, I can write my code accordingly.

I am not sure how your way work for you and don't have time to investigate
but on Windows is a way to use win api call ..like is explained on this site

https://aljensencprogramming.wordpress.c...win32-api/

I just tried this threading once in freeBasic and i was not happy with results.

I'm using pthreads which is built into QB64, in all of the platforms. So, I avoid anything that would exclude one platform or another. I personally use Linux for 99% of everything, but I understand that I'm a minority. 

My first "working" threading attempts were disappointing, but I began to understand my implementation was wrong.

[DSMan195276]

I'm very well aware that QB64 is not designed for this. I stated this in the last paragraph. In my numerous failed attempts, I'm beginning to learn where the boundaries are. Once, I understand the boundaries, I can write my code accordingly.

Right, I'm just saying that I know how the QB64 internals work and so I know many of the limitations you're going to hit, and they're so limiting that you basically won't be able to do anything:

1. You cannot call any subs or functions from the threads
2. The threads cannot have any local variables
3. The threads cannot use any strings
4. The threads cannot redim any arrays
5. You cannot start the threads from anywhere except the main code.
6. You cannot use the bulk of the built-in commands
7. You cannot have any errors happen, no `ON KEY` entries, no timers, etc.

Basically all that leaves you able to do is interact with shared non-String variables. That's not a whole lot, and you still have some broken aspects that are not solvable.

The other big reason I'd not recommend it is that the "boundaries" are tied to specific versions of QB64. We make significant changes to the runtime in many releases which change what you can or cannot do in your threads, you're going to end up with code that works in one release and not the next.

[a740g]

So, write the entire thread callable code in C/C++, avoid any calls to the QB64 runtime, and use shared memory that does not move in memory to exchange data.

This approach seems to defeat the purpose of using BASIC. Still, it might be useful in some niche cases.

This gives me some weekend ideas. 

[DSMan195276]

So, write the entire thread callable code in C/C++, avoid any calls to the QB64 runtime, and use shared memory that does not move in memory to exchange data.

This approach seems to defeat the purpose of using BASIC. Still, it might be useful in some niche cases.

This gives me some weekend ideas. 

Yeah pretty much, the reliable option here is to write all the code running in the thread in a different language like C++. You can expose mutexes and lock/unlock functions for them to the QB64 code to protect memory that's being shared.

[justsomeguy]

Hello all,

I have another test program that uses threads. This time it creates from 1 to 8 worker threads and they draw colored squares across the screen.

As before it needs a header file to setup threading. Its name is 'workers.h'

Code: (Select All)

// workers.h
// Threading Header
#include "pthread.h"
// Only needed for the SIGTERM Constant
#include <signal.h>
#include <unistd.h>
#include <time.h>

#define RETRYCOUNT 5
// Initialize Threads
static pthread_t thread[9];

typedef struct thread_data {
   int id;
} thread_data;

// Easy was to determine if a thread is running
bool threadRunning[] = {false,false,false,false,false,false,false,false,false,false};

// Setup Mutexes.
static pthread_mutex_t mutex[9];

// QB's names for the threaded Subs
// You can locate these in your ''qb64pe/internal/temp'' folder.
// I found these in the 'main.txt'
void SUB_WORKERTHREAD(int32*_SUB_WORKERTHREAD_LONG_ID);

// wrap the subs so that you can easily get the void* for pthread
void* RunWorker(void *arg){
    thread_data *tdata=(thread_data *)arg;
    int a = tdata->id;
    SUB_WORKERTHREAD((int32*)&a);
}

// These are the commands that are accessed by you program
void invokeWorker(int id){
    thread_data tdata;
    tdata.id = id;
    int icount = 0;
    if (!threadRunning[id]) {
        while(pthread_create( &thread[id], NULL, RunWorker, (void *)&tdata))
        {
            icount++;
            if (icount > RETRYCOUNT){
                return;
            }
            sleep(1);
        };
        pthread_mutex_init(&mutex[id], NULL);
        threadRunning[id] = true;
    }
    sleep(1);
}

void joinThread(int id){
    pthread_join(thread[id],NULL);
    threadRunning[id] = false;
}

void exitThread(){
    pthread_exit(NULL);
}

void killThread(int id){
    if (threadRunning[id]) {
        int iret = pthread_kill(thread[id], SIGTERM);
    }
}

void lockThread(int id){
    pthread_mutex_lock(&mutex[id]);
}

void unlockThread(int id){
    pthread_mutex_unlock(&mutex[id]);
}

And the QB side is as follows. Its name is whatever you like.

Code: (Select All)

DECLARE LIBRARY "./workers"
  SUB invokeWorker (BYVAL id AS LONG) ' start Lines thread
  SUB joinThread (BYVAL id AS LONG) ' wait til thread is finished
  SUB exitThread ' must be called as thread exits
  SUB killThread (BYVAL id AS LONG) ' kill the thread
  SUB lockThread (BYVAL id AS LONG) ' mutex lock
  SUB unlockThread (BYVAL id AS LONG) ' mutex unlock
END DECLARE
 
TYPE tWorker
  xstart AS LONG
  ystart AS LONG
  xsize AS LONG
  ysize AS LONG
  xdir AS _BYTE
  x AS LONG
  y AS LONG
  colour AS LONG
  command AS LONG
  sc AS LONG
  img AS _MEM
  offset AS _OFFSET
  dly AS _BYTE
END TYPE
 
DIM indx AS LONG
DIM ky AS STRING
DIM AS INTEGER tc
 
_TITLE "Worker Thread Test"
 
SCREEN _NEWIMAGE(800, 600, 32)
DO
  CLS
  PRINT "How many worker threads? Low spec machines should start less than 4."
  INPUT "(1 - 8, 0 to quit):"; tc
  IF tc = 0 THEN SYSTEM
LOOP UNTIL tc >= 1 AND tc <= 8
tc = tc - 1
CLS
 
DIM SHARED AS tWorker worker(tc)
 
FOR indx = 0 TO tc
  resetWorker indx
  worker(indx).sc = _NEWIMAGE(worker(indx).xsize + 1, worker(indx).ysize + 1, 32)
  worker(indx).img = _MEMIMAGE(worker(indx).sc)
NEXT
LOCATE 1
FOR indx = 0 TO tc
  PRINT "Starting thread:"; indx
  invokeWorker indx
NEXT
CLS
DO
  ky = INKEY$
  IF ky = "d" THEN
    FOR indx = 0 TO tc
      worker(indx).dly = NOT worker(indx).dly
    NEXT
  END IF
 
  IF ky = "s" THEN
    CLS
    FOR indx = 0 TO tc
      worker(indx).command = NOT worker(indx).command
      IF worker(indx).command THEN
        joinThread indx
      ELSE
        PRINT "Restarting thread:"; indx
        _DISPLAY
        invokeWorker indx
      END IF
    NEXT
    CLS
  END IF
 
  IF ky = CHR$(27) THEN
    FOR indx = 0 TO tc
      worker(indx).command = -1
      joinThread indx
      SYSTEM
    NEXT
  END IF
 
  FOR indx = 0 TO tc
    _PRINTSTRING (indx * 100 + 10, 220), "Worker:" + STR$(indx)
    _PUTIMAGE (indx * 100, 250), worker(indx).sc
  NEXT
 
  _PRINTSTRING (10, 380), "Press 'd' toggle thread slowdown. Press 's' to start/stop threads. Press 'ESC' to exit."
  _LIMIT 60
  _DISPLAY
LOOP
 
SUB resetWorker (id AS LONG)
  worker(id).xsize = 100
  worker(id).ysize = 100
  worker(id).xstart = 0
  worker(id).ystart = 0
  worker(id).x = worker(id).xstart
  worker(id).y = worker(id).ystart
  worker(id).xsize = 100
  worker(id).ysize = 100
  worker(id).xdir = 1
  worker(id).colour = _RGB32(RND * 255, RND * 255, RND * 255)
END SUB
 
SUB workerThread (id AS LONG)
  DIM AS INTEGER dly
 
  DO
    lockThread id
    IF worker(id).x + worker(id).xdir > worker(id).xstart + worker(id).xsize OR worker(id).x + worker(id).xdir < worker(id).xstart THEN
      worker(id).xdir = -worker(id).xdir
      IF worker(id).y + 1 > worker(id).ysize THEN
        resetWorker id
      ELSE
        worker(id).y = worker(id).y + 1
      END IF
    ELSE
      worker(id).x = worker(id).x + worker(id).xdir
    END IF
 
    worker(id).offset = worker(id).img.OFFSET + (worker(id).x * 4) + (worker(id).y * worker(id).xsize * 4)
    _MEMPUT worker(id).img, worker(id).offset + 0, _BLUE32(worker(id).colour) AS _UNSIGNED _BYTE
    _MEMPUT worker(id).img, worker(id).offset + 1, _GREEN32(worker(id).colour) AS _UNSIGNED _BYTE
    _MEMPUT worker(id).img, worker(id).offset + 2, _RED32(worker(id).colour) AS _UNSIGNED _BYTE
    _MEMPUT worker(id).img, worker(id).offset + 3, 255 AS _UNSIGNED _BYTE
 
    IF NOT worker(id).dly THEN dly = 0: DO: dly = dly + 1: LOOP UNTIL dly < 0
    unlockThread id
 
  LOOP WHILE worker(id).command = 0
  exitThread
END SUB

[DSMan195276]

@justsomeguy just some notes from looking at your code:

1. Don't pass `tdata` on the stack to the thread. You should use  something like `malloc()` to allocate it because you don't know when the other thread will actually start using it, it could happen after invokeWorker returns.
2. Your mutexes aren't doing anything because each thread has its own. You should also initialize them before starting the thread.
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.
4. I wouldn't declare the`dly` integer inside the SUB.
5. Calling `resetWorker` from the worker thread is not safe.

I would also recommend putting the worker thread `SUB` inside of a `$CHECKING:OFF` block, that will prevent QB64 from inserting the error handling logic into the code for your thread.

[justsomeguy]

@DSMan195276

Thank you for you suggestions.

1. Don't pass `tdata` on the stack to the thread. You should use  something like `malloc()` to allocate it because you don't know when the other thread will actually start using it, it could happen after invokeWorker returns.

I would appreciate it if you go into more detail on this. Perhaps some sample code?

2. Your mutexes aren't doing anything because each thread has its own. You should also initialize them before starting the thread.

I thought this was the case, so commented them out and had same results.

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.

4. I wouldn't declare the`dly` integer inside the SUB.
5. Calling `resetWorker` from the worker thread is not safe.

These are me testing the boundaries. Clearly, in production code, I would go different route, like writing it in a different language.