I'm not sure, but on Linux, I imagined having promoted Pd's priority as a process (sched_setscheduler(0,SCHED_FIFO,&par)) would affect all its threads. If not, I'd better do as you suggest :)
I don't know what happens in Windows or MacOS...
cheers Miller
On Tue, Oct 06, 2015 at 06:15:21PM +0200, Kjetil Matheussen wrote:
My questions are:
- Have I completely misunderstood d_soundfile.c and it is actually
entirely safe. If so, why is it safe?
It depends whether the OS implements priority inheritance ( https://en.wikipedia.org/wiki/Priority_inheritance). I think Windows does something like this, not sure, and perhaps Mac OS X too. In Linux, you must call pthread_mutexattr_setprotocol(mutex, PTHREAD_PRIO_INHERIT) to get priority inheritance for your lock. Alternatively, you can just boost the priority manually before obtaining the lock, and unboost after releasing.
- Why doesn’t Pd glitch more often when using these objects?
Probably because the lock is held for so short durations that the OS very
seldomly has had the chance to interrupt the thread, and for those few times it has happened, no real time priority thread had suffered from it, and for those very very very few times where a realtime priority thread has suffered, it hadn't suffered enough to cause a glitch.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list