OS4 pthread.library usage experience wanted

I'm considering the use of pthreads.library in order to implement threads in wxWidgets, however I wonder if there are any drawbacks doing this ? Specifically will there be any restrictions in the created threads to use standard Amiga API ?

@abalaban

there are only few missing functions in os4 and iirc the semaphore implementation
If you want to be sure try all the tests you can find here:

https://computing.llnl.gov/tutorials/pthreads/

is the best tutorial i've found

@afxgroup

thank you for this link, very useful. In fact I was rather looking for information about the OS4's pthreads implementation. And I was interested in any problem there might be in it or any restriction its usage might impose for the created threads in the use of the Amiga API.

For example it seems to me Bean switched back from pthreads to native Amiga API in Tunenet because of problems.

@abalaban

I switched from PThreads to my own process management system due to a number of non working schedualing functions. Apart from that the implementation was pretty sound.

Cheers,
Bean.

@abalaban

I would say if you are porting existing code that uses pthreads then, use pthreads under OS4. Otherwise unless you need something specific from the pthread API write your own code using amigaos tasks and stuff.

I don't think there any limt on what you can do WRT the AmigaOS API in a pthread. You may have to be careful about altering task user data perhaps, as pthreads might use that (not 100% sure on that but I think I 'read it somewhere TM')

@broadblues & bean

Thank you for this information, I think I'll give a try on pthreads then...

@abalaban

you could look at wxlua, it has code for WxWidgets using lua
http://wxlua.sourceforge.net/

some threadinfo:
http://www.ibm.com/developerworks/linux/library/l-ipc2lin1.html

@abalaban

The actual problem I was having with pthreads on OS4 was when using the pthread_attr_setinhertisched() function, it would always fail when I used the attribute, PTHREAD_EXPLICIT_SCHED. (This then meant I coudn't use the pthread_attr_setschedparam() function.)

I think Thomas Frieden then confirmed that this wasn't fully implemented. So instead of mixing pthreads and AmigaOS process related API calls I wrote my own class to ease the handling, which was built up from the standard AmigaOS API calls. (I now use this class all over TuneNet).

Cheers,
Bean.

@abalaban

The guy who is working on porting Blender (not Thomas Frieden, but Broadblues who independently started porting it) noticed a number of issues. The threads library currently also misses rwlocks.

Hans

@Hans

Strictly I found one issue in two places. Under some hard to reproduce conditions a pthread and it;s parent thread can both seem to end up waitng for a semaphore. It's hard to reproduce in terms of a simple code example that I can give to Rogue to test. (I must try to have another go at that soon, just can't find any programming time ATM.) not so hard to get to happen.

It seems to occur when new threads are being spawn at the same time as another tasking is using lot's of or a surge of cpu time. Such as rendering an animation with blender (make lost of pthreads) and browseing the net, sudden surges of image decoding.

The threading thing that's really giveing me problem in blender at the moment, is the SDL_Audio thread, which blender tries to kill on exit, fails and goes into a busy loop. This is an "SDL thread" and nothing to do with pthreads though.

@abalaban

OK, sorry if I'm about to waste everybodys time, but something I've noticed whilst using the latest MPlayer to play an "mms" stream.

I just happened to have snoopy open and after closing MPlayer, this was left running, endlessly repeating...

00188 : pthread id 1 : o.k. = [exec] OpenDevice("timer.device",0,0x6A6884C0,0x00000000) = 0 [56uS]

It was'nt snoopy's window playing catch-up, because the "lines queued" count kept increasing, eventually after an hour or so the machine would come to a halt. I only mention this at it is "pthread" related
Richard.

@All

With AOS4.1.1, pthreads.library produce also the following problems:

- A program who use pthreads idxx threads (for managing datas from internet to the computer) could have all the threads in wait semaphore mode and the program simply stop working.........

- This problem allways exist or have been corrected ???

- If not corrected, what solution exist to temporarly stop this problem ???


Would like to knowwif this problem (thread all in semaphore state) came from AOS or the program itself....

Thanks for the answers...