Multithreading with GLBasic [official]

[Kitty Hello]

Yes, its an altered version of hawkthreads.

[bigsofty]

Many thanks, now I have the docs I can read into it a little more(no guarantee It will sink in though!  ).

[jestermon]

Just when I got halfway with "INLINE"ing a "c" threading solution, I find this post. . . (Should I cry or laugh?)
A small example of this thread in use - in Basic - could streamline things all around.. Would this be possible? (An example)

[bigsofty]

There is a very small example already included with the lib I think.

[jestermon]

Ah yes, thanks.

[Gary]

Been using this lib for a while though and always had a windows alert and an UNHANDLED EXCEPTION alert in the debug window when exiting a program but as the code was never actually being quit I never bothered looking for it until today and it turns out my thread is causing the issue

I am setting the thread up with the following command

Code: (glbasic) [Select]

// Create a Mutex
mx_mutex=ThMutexCreate()

// Start a new thread
IF ThThreadCreate("Interrupt")=FALSE
PRINT "Can't create thread", 0,0
SHOWSCREEN
MOUSEWAIT
END
ENDIF
But how should I be handling it on app close? I thought that by doing

Code: (glbasic) [Select]

ThMutexDelete(mx_mutex)before the end command would do the trick but I still get the exception.

I am 100% certain its the thread that is causing the alert as when I dont initialise it then the code exits correctly.

Any help would be appreciated

EDIT: Found the issue, my code used the thread as a pseudo interrupt and the subroutine actually never quit, it did the code in a while 1 loop. Once I forced a graceful exit from the SUB before I deleted the Mutex it removed the error on shutdown. So the lesson is, make sure the thread is not running when you delete and exit

[bigsofty]

Interesting, I never actually used this lib regretfully as I was never 100% confident that some little non-thread safe peice of external code would rear its ugly head.

It sounds like you are not(exiting to one side) have has any such problems Gary?

[Gary]

No problems what so ever Bigsofty. It sat in the background running set code on a 20 50 100 250 and 500 ms interval with no issues. Admittedly it was not a massive amount of code but it still worked

[bigsofty]

That's nice to know! 

What are you using your interrupt for BTW?

[Gary]

I was writing a video fruit machine and wanted it to be as close to the operating system I used for physical reel based machines where I basically "fire and forget" things like telling a lamp to flash or start the reels spinning or checking if a button was pressed. So within my graphic draw routines I have a flag for each graphic, lit and unlit, and I attach a status flag to each image saying which to draw. The interrupt can toggle these flags at a very specific interval to create flashing images. Also the reels have a flag to say stopped, spinning, stop at a position, bounce back and nudge. Again all this movement is controlled by the interrupt and not the main draw routine. Possibly I over engineered the solution but it works for me

[bigsofty]

Interesting way of doing it. Well you've perked my interest in GLB threads again, I'll have a think on how I can use them in my game! 

[kanonet]

Actually I think that is the wrong way of approaching this, bigsofty. If you have a problem in your game that you can not solve any other way, than it may be worth to try it with multithreading. But you should not just include it, just because you want to. Threads add huge extra complexity, some overhead and many sources of possible bugs. In many cases threads dont get you anything, so you should avoid them if possible and only use them when really necessary.
BTW many GLBasic commands are not thread  save, so be careful what you pack inside a thread. That 'official' in the title is very misleading IMHO, since GLBasic was not designed with threads in mind.

[bigsofty]

Thanks Kanonet, I've used multithreading in other languages in the past which were thread safe and I do understand the risks with non-threads age code. I will probably avoid the GLB runtime lib altogether and even then stick to inline C. The single core restriction is a real pain TBH, even getting some of the CPU power back would be a real boost. But yes, I'm very restricted to mainly calculations and even then the 2nd thread has to be almost independent of the 1st with careful mutex handling. AND even then it will be labeled as experimental for a long time.

Thank you for you word of caution though.