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. :-)

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

Hi Mathieu,

Btw^2, I'd like to know, how does malloc() work with pthreads? how does it achieve threadsafety? what's the impact on realtime?

The MSVC memory allocation routines at least use quite complicated fully lockfree algorithms. Given that, the impact on realtime shouldn't be to big.

How about changing sys_lock to something like this:

void sys_lock(){ if(pd_is_running_realtime() && caller_is_not_running_realtime()){ post("Error! You must run your thread with realtime priority to be allowed to call sys_lock. Period!"); abort(); } ... }

On Tue, 13 Dec 2005, Thomas Grill wrote:

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

On Wed, 14 Dec 2005, Thomas Grill wrote:

Kjetil S. Matheussen schrieb:

...

How about changing sys_lock to something like this:

void sys_lock(){ if(pd_is_running_realtime() && caller_is_not_running_realtime()){ post("Error! You must run your thread with realtime priority to be allowed to call sys_lock. Period!"); abort(); } ... }

What would be gained by that?

To ensure that the caller won't block PD, unless the caller explicitly calls fread, usleep or other non-realtime functions while holding the lock.

I definitely think something like that should go in. If you are not running realtime and aquire the lock you potentionally can screw up the sound in a way that can only be solved by letting yourself be running realtime.

On Wed, 14 Dec 2005, Tim Blechmann wrote:

...

...

What would be gained by that?

To ensure that the caller won't block PD, unless the caller explicitly calls fread, usleep or other non-realtime functions while holding the lock.

well, it's not as easy as that ... pd is not designed to be a multithreaded application ... so someone could just say ... "don't use threads"

I don't understand why its not as easy as that... Theres nothing wrong using threads and locks as long as all of them is running realtime.

You already know the following, but just to clarify: You have a problem if a realtime thread is waiting on a non-realtime thread, then, any non-realtime thread in the system can interrupt the realtime thread. My proposial for sys_lock eliminates that particular problem.

On Wed, 14 Dec 2005, Tim Blechmann wrote:

...

...

well, it's not as easy as that ... pd is not designed to be a multithreaded application ... so someone could just say ... "don't use threads"

I don't understand why its not as easy as that... Theres nothing wrong using threads and locks as long as all of them is running realtime.

You already know the following, but just to clarify: You have a problem if a realtime thread is waiting on a non-realtime thread, then, any non-realtime thread in the system can interrupt the realtime thread. My proposial for sys_lock eliminates that particular problem.

just take it as design fault of pd :-/

Well, I'm very well aware of how pd works. I'm just trying to propose a solution to one particular problem.

hi kjetil,

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. :-)

i know ... priority inversion and all the stuff ... the problem of the threadsafe gensym implementation ... it's using a thread lock, too ... although only for the inserting into the hash table ... i've got a lockfree thread safe implementation of a hash table on my hard drive, but i wrote it in c++ and it's only tested on x86/linux ...

t

...

i know ... priority inversion and all the stuff ... the problem of the threadsafe gensym implementation ... it's using a thread lock, too ... although only for the inserting into the hash table ... i've got a lockfree thread safe implementation of a hash table on my hard drive, but i wrote it in c++ and it's only tested on x86/linux ...

But its the same hash that is created anyway right? So all I got to do is to cut and paste pd-s gensym implementation into my code and call the function and hash-table for something else, and then I'm done.

not exactly ... what you could do is to take my code from devel and replace the hashtable lock by the sys_lock

t