[PD-dev] [ pure-data-Patches-3322973 ] make clocks thread safe
SourceForge.net
noreply at sourceforge.net
Mon Jun 27 15:20:39 CEST 2011
Patches item #3322973, was opened at 2011-06-20 11:59
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3322973&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: puredata-dev
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: make clocks thread safe
Initial Comment:
when writing threaded externals, i often find myself wanting Pd to call a callback from the main thread, depending on the "other" thread's state.
e.g. when doing asynchronous data acquisition, i want to notify Pd when new data has arrived, so it can be delivered in the main thread.
the obvious way is to use t_clock, and registers a new clock_delay() event from within the helper-thread; Pd will then callback in the next tick.
unfortunately the clock_set(),... methods are not thread safe, possibly leading to corruption of the clock_setlist when accessing them simultaneously.
one workaround is to use the global sys_lock(), but i find this to terribly slow down the entire Pd process, esp. when i have to call sys_lock() multiple times before ticks. that's most likely because sys_lock() locks about everything.
an alternative i used in the past, is to have a special (mutex-protected) flag, indicating whether i already have a clock running that is waiting to be called back from the main thread.
however, i find this quite complicated
therefore, i propose to make the clock_delay/clock_set/clock_unset methods threadsafe, by internally maintaining a separate mutex that solely protects the clock_setlist.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-06-20 13:24
Message:
just a few final words:
the problem i describe can well be solved with sys_lock()
however this creates a "Big Kernel Lock", potentially affecting
performance.
my proposal is to use finer grained locking, to avoid problems with the
BIG syslock.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-06-20 13:19
Message:
i have also written a small external that illustrates the problem.
find it in the "threadclock.tgz" archive, and compile it.
the object will create a number of threads (use the argument to specify
how many threads you want);
each thread will sleep for a short time (100ms or so), and then call
clock_delay() to wake up the object from the main thread.
sooner or later, this will crash Pd; using my path it won't
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-06-20 12:05
Message:
attached is a first draft (against todays git master)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3322973&group_id=55736
More information about the Pd-dev
mailing list