[PD-dev] [ pure-data-Bugs-3337413 ] Big system lock won't be released in some circumstances

[SourceForge.net]

Bugs item #3337413, was opened at 2011-06-27 15:51
Message generated for change (Tracker Item Submitted) made by zmoelnig
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3337413&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pd-devel
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: Big system lock won't be released in some circumstances

Initial Comment:
i'm currently working on some threading support in Gem, where i use sys_lock()/sys_unlock() to protect my calls to clock_delay().

while testing i noticed that the syslock was never unlocked by Pd in certain circumstances:
- i was using no audio (SCHED_AUDIO_NONE)
- my patch used up quite a lot of CPU (rendering a teapot without openGL acceleration)

in my worker-thread i called "sys_lock()", and i never got beyond this point.

after a lot of searching i found the reason:
  in the mainloop, Pd will call sys_unlock() ONLY if it has a valid audio-backend OR it has idletime ("unlock while we are idle")

in my case, neither was true (the latter, because one of the cores was busy rendering a teapot)

this is unexpected behaviour since:
- i'm using multiple threads to get more performance out of my multicore system; if i moved all the work done by the helper thread into the main thread (to avoid the use of syslock) performance would be dramatically worse
- when i chose an(y) audio-backend, my helper threads will be unlocked, even though using audio could be expected to take even more time to calculate (hence an additional thread can be seen as even more undesireable when running under full load)

suggested solutions:
- when no audio-backend is used, the syslock should be unlocked/locked, so waiting threads have a chance to get scheduled
AND/OR
- get rid of the big system lock; in my special case it would be enough to have a thread-safe version of clock_delay() see [1] for a patch that implements this

attached is a patch (against current git) that unlocks the syslock for a tiny period (and immediately locks it again) when using no audio backend, so waiting threads get a chance to be scheduled by the OS.




[1] thread save clocks: https://sourceforge.net/tracker/?func=detail&aid=3322973&group_id=55736&atid=478073

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3337413&group_id=55736