Hi Kjetil, to my mind using syslock is dangerous in any case, because if the lock is held by someone else you might wait up to 1 ms (depending on your OS turnaround frequency) at this point. Of course it depends on how often you use gensym, but i would avoid it.... (although i introduced it... my bad)
greetings, Thomas
Am 13.12.2005 um 23:04 schrieb Kjetil S. Matheussen:
On Tue, 13 Dec 2005, Kjetil S. Matheussen wrote:
On Tue, 13 Dec 2005, Kjetil S. Matheussen wrote:
On Tue, 13 Dec 2005, Tim Blechmann wrote:
hi kjetil,
I'm working on the snd external, and wonder about gensyms thread safety. It looks to be, but I'm not quite sure. In case it isn't is there a locking-mechanism or something I can use? I also see that there are some functions called sys_lock or something, how does they work?
gensym is basically not thread safe ... for the devel branch i made gensym threadsafe, but if you want to write code for miller's pd, you need to use the syslock ...
Thanks! So how do I use syslock from another thread? Does this make sence:? t_symbol *thread_safe_gensym(char *symbol){ t_symbol *ret; sys_lock(); ret=gensym(symbol); sys_unlock(); return ret; }
Hm, no, actually, I can't do that. Snd isn't running with realtime priority, so if pd needs to wait for snd, pd will in practice lose its realtime priority when it has to wait for Snd. Miller P.: Please apply Tim's threadsafe gensym to your version. :-)
Oops, of course, I can just do it like this:
t_symbol *thread_safe_gensym(char *symbol){ t_symbol *ret; struct sched_param par; par.sched_priority = sched_get_priority_max(SCHED_FIFO); sched_setscheduler(0,SCHED_FIFO,&par); sys_lock(); ret=gensym(symbol); sys_unlock(); sched_setscheduler(0,SCHED_OTHER,&par); return ret; }
--
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev