Now that the majority of the usability enhancements have gone "mainstream," (yay! thanks, Miller!) I see little reason to make Mac users use a forked version. I'll do what I can to help make sure installation is easier, but I don't see a pressing need for a full distro for the CVS version. Thoughts?
Yes, Miller, also thank you very much for including pd_newest... it's a great help for playing with dynamic object creation.
The only thing that i'm still missing is some thread-safety for the clock functions. I know that my implementation in the devel_0_36 is problematic because a second thread can hold the system thread with the thread mutex.... hmmm, it would be interesting for how long.... the code insinde the mutex is really _very_ short, but is there some time granularity associated with mutex locking/unlocking? Don't know...
best greetings, Thomas
but is there some time granularity associated with mutex locking/unlocking? Don't know...
Oh, i did some short tests and can say that at least for the Windows pthreads implementation there isn't any additional time jitter imposed by thread locking/unlocking (it seems like the normal multi-threading jitter is much higher). Threads seem to immediately continue running as soon as they are unlocked.
greetings, Thomas
Could these threaded clock functions be the cause for the problems Hans Christoph reported with the CVS version ?
Guenter
On Sun, 4 May 2003, Thomas Grill wrote:
but is there some time granularity associated with mutex locking/unlocking? Don't know...
Oh, i did some short tests and can say that at least for the Windows pthreads implementation there isn't any additional time jitter imposed by thread locking/unlocking (it seems like the normal multi-threading jitter is much higher). Threads seem to immediately continue running as soon as they are unlocked.
greetings, Thomas
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Hi,
Could these threaded clock functions be the cause for the problems Hans Christoph reported with the CVS version ?
I don't think there are any influences on externals which don't use threads. It's only a local mutex that is solely used by the clock functions and only if they are called concurrently by separate threads. Also, it's quite unlikely that a mutex lock will occur, that's why also with my massively threaded vasp library i never encountered problems while working with the standard pd distribution.
My tests with the pthreads implementations revealed no critical timing delays associated with mutex locking. One thread lock/unlock passage requires about 0.03 ms (Pentium 200/Linux and PIII-800/Windows). As the locking code in clock_set is very short this should be the maximum observed delay when using threads.
However, i'll revisit Hans Christoph's problem report as soon as my IMAP server is running again....
greetings, Thomas
-
guenter geiger -
Thomas Grill