[PD] readsf~ and writesf~, locking, blocking and real-time priority

[Miller Puckette]

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:
> >
> > 1) 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.
> 
> 
> 
> > 2) 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list