If both method invocations initialize by reading the 'all off' state, then whichever one finishes last will effectively turn the first one back off.
With all these things built in, at a given time, over 3 different things can be controlling the FB. To remedy this, I've multi-threaded the crap out of the python application so that nothing will block anything else ever.
All that explanation was just so you don't say "why the heck are you doing this?" haha
THE REAL PROBLEM:
So in my application, I have a method called turnOnOutput(x) with x being the output's number.
The method, turnOnOutput, then launches a new thread and that thread hits FBD on the DBUS. This allows turnOnOutput to return instantly so that the http request won't time out, or even just take annoyingly long.
However since this is receiving communication from all sides, the DBUS gets quite busy. So I just went through the application and if a few conditions are met at the same time which is quite feasible when the car is first being turned on, turnOnOutput will get called 10 times one right after the other. This sets off 10 threads that attack the FBD on the dbus 10 times. All while sensors are continuing to be read ever few milliseconds.
Now from what I can gather from what newkirk has said it seems like FBD is requesting the ports that are on from the fusion brain, receiving that request, and then actually telling it whether to turn the port on/off. So now lets say things get a bit out of order...
Now, newkirk has explained the race condition fairly well in post
Originally Posted by newkirk
Now I have a question...
Why the heck does it need to read in 16 output statuses to set one output?
Why does it even need to read ONE output status to set an output?
Why can't efficiency and reliability just be saved by actually just going ahead setting the output?
I'll get around to fixing the reliability issue soon, and that might fix the other issue
I just scanned this discussion as I have been away for a few days. If you have multiple processes/threads trying to updated the FB, you'd be better off queuing the updates and having a single thread that waits for updates on the queue and services them (although I guess you can use dbus as the queue??). If there are multiple updates on the queue, have it do some kind of merge or just take the most recent. Either way, with only one thread writing, the results should be consistent.
Sadly I have not had the time to play with my FB beyond the initial brief dabbling (nor any carputer stuff in general).