[PD-dev] outlet_anything() & threads

[IOhannes m zmoelnig]

Christian Klippel wrote:
> 
>> if you "guarantee" (e.g. leave it at the users discretion :-)) that no
>> unprepared object will be involved in several threads, the i guess you
> 
> what do you mean by "unprepared objects" ? other objects that use threads too? 

by "unprepared object" i mean objects that are not aware that they might 
receive messages in 2 different threads.
the only object i *think* that is "prepared" in this sense is tim's 
[join] object.

> as for the actual code in question, it creates only one single thread to read 

which makes 2 threads in total (your helper-thread and pd's main thread)

> from the usb bus, and send data to the outlets if anything arrives. there are 
> no other threads created.... an there are no variables/memory that the thread 
> shares with the rest of the external's code, except for sending to usb, which 
> is synchronized ....

that shouldn't be a problem.
however, as soon as you are talking with the rest of pd (e.g. via 
outlet_anything()) you cannot ensure anymore that the 2 threads have 
separate variables,...

> 
> what im wondering is, how can one stress-test such a situation to see if it  
> works just by accident now, or if it is reliable ....

that's the nature of race-conditions: somebody wins the race and you 
cannot tell in advance who does (the whole bet-and-win commerce depends 
on that).

and even if the chance of loosing the race is 1:1e38 you are likely to 
have it exactly when you are to do the show....(however, you might get 
good conditions for this case at your local insurance agency, so it will 
do no harm to you - and the rest is covered by the license of the 
involved software)

> 
> so im really wondering how that could work, if it isnt supposed to be safe to 
> call outlet_anything from a (single) thread ....

again, it is not a _single_ thread, but two (that's why there will be 
problems)

problems will appear if one objects gets messages from 2 separate 
threads (and is not aware of this).

sthg like:

[metro 1]     [threadObject]
|             |
[anotherObject]

additionally it might well be that one object will more easily a problem 
with multiple threads:
e.g: if you are sending messages to [==] from a single object, you might 
only get corrupted values. (e.g. sending [1 1( in one thread might give 
you "0" (which means that 1!=1), since the concurrent thread has reset 
the 2nd value between receiving the value list and outputting the 
result; this is most likely a non-fatal behaviour (but mathematicians 
might disagree)

you will get more problems with objects that allocate and free memory on 
demand (without being thread save; and most pd objects are not!): e.g. 
accessing an array in one thread and resizing it in another thread is 
more likely to crash.

> 
> and as tim said:
> 
>> solution 3: use flext, since it's taking care of that ...
> 
> tim, since i know nothing about flext (yet), just a few quick question (maybe 
> i asked that loong ago alread....): does it work on linux/os-x/win? i need 
> all three ....

yes it does work on all three of them.
and it also works for max/msp.
and it also has drawbacks :-)


mfg.asdr
IOhannes