Rigs of Rods

we have a stream locking mechanisms:

LOCKSTREAMS();
UNLOCKSTREAMS();

but these are only for network purposes :-/

No need to guard the trucks array with mutexes. We could bring all truck insertions and deletions into the thread that runs the simulation (calcEuler). Or have a small journal, containing truck deletion and insertion actions that will be acted upon at specific times that won't create collisions.

estama wrote:

No need to guard the trucks array with mutexes. We could bring all truck insertions and deletions into the thread that runs the simulation (calcEuler). Or have a small journal, containing truck deletion and insertion actions that will be acted upon at specific times that won't create collisions.

yes, i thought that would be the case already. I have such a journal running in order to decouple the network thread and the beam / ogre thread.

All truck creations/deletion should be done in the ogre thread. Seems we forgot a bit, since it crashed. :-\

Thomas, in which parts of the code do trucks get added or deleted? Are these parts of the code in the same thread as trucktruckcollisions?

Thomas is the ogre thread the same as the calcEuler thread? If not then we have a major problem, because trucktruckCollisions is in the calcEuler thread.

estama wrote:

Thomas is the ogre thread the same as the calcEuler thread? If not then we have a major problem, because trucktruckCollisions is in the calcEuler thread.

checking now ...

Now that i'm looking at the code, it isn't just the trucktruckCollisions that is problematic. The whole of Beam::threadentry has the same synchronization problems.

This code for example (above trucktruckcollisions):

            for (t=0; t<numtrucks; t++)
            {
                if(!trucks[t]) continue;
                                ...........
                                ...........
                trucks[t]->calcForcesEuler(i==0, dtperstep, i, steps, trucks, numtrucks);

Can crash if a truck is deleted between the !truck check and calcforceseuler.

estama wrote:

Now that i'm looking at the code, it isn't just the trucktruckCollisions that is problematic. The whole of Beam::threadentry has the same synchronization problems.

This code for example (above trucktruckcollisions):

[...]

Can crash if a truck is deleted between the !truck check and calcforceseuler.

also realized that now. :-\

so should we create a:

1) create a journal and delete in the beam thread, and lock in the ogre thread?
2) lock the beam thread and leave deleting as it is: in the ogre thread?

I prefer the journal way. I suspect that it could even be done without locks, by using circular buffers. The Ogre and network threads will write commands at the buffer's head, and the beam thread will read and execute them starting from the tail.

The quickest (and safe) way to fix this is:

- Add a new attribute "todelete" to truck's class.
- Instead of deleting a truck, change this attribute to true where right now a truck gets deleted.
- Just before calling trucktruckcollisions, scan all the trucks to see if they have "todelete==true" and delete them.

This would guaranty that a truck won't get deleted while trucktruckcollisions runs. Adding a truck while trucktruckcollisions runs shouldn't present a problem. If it is, then it is fixable in more or less the same way.