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