Reading - modifying vector from different threads.

[Tzarls]

I'll have a look at this, but the real problem is not the vector itself, but the data stored in the vector and the posibility of having invalid pointers being accessed by the audio thread. After having considered for a few hours I think reference counting is the best solution for this problem, and considering the way I've implemented my classes it should be fairly easy to add that feature to my objects.

[zman]

You can update the tree in your blockManager::process at the beginning. So only what you need its a fifo for insert update and delete actions. In the guiThread
you insert the modifications in the fifo and in your blockManager::process funktion you trigering the actions so long the fifo its not empty.
After this you must notify the guithread to redraw.

[Tzarls]

Update:

The job was finally done using what zman suggested: using a FiFo to queue insert and delete actions, and updating the tree at the beginning of blockManager::process only if there's anything in the FiFo.

I also implemented Reference Counting to better manage the lifetime of my objects, specially those running scripts that could be still working when the user deletes the correspondig object. Since the script holds a reference to the object calling it, the object is only gone once the script returns (with its task completed or interrupted).

Thanks for all your answers.

[aciddose]

http://stackoverflow.com/questions/3447 ... turn-index

[thevinn]

a FiFo to queue insert and delete actions, and updating the tree at the beginning of blockManager::process

This is exactly the approach used in DSP Filters:

Thread queue:

https://github.com/vinniefalco/DSPFilte ... eadQueue.h

[Jeff McClintock]

I also implemented Reference Counting to better manage the lifetime of my objects, specially those running scripts that could be still working when the user deletes the correspondig object. Since the script holds a reference to the object calling it, the object is only gone once the script returns (with its task completed or interrupted).

I went a little further an implemented 'handles', so rather than holding a pointer to an object (that might get deleted at any time), the GUI and corresponding DSP objects hold the same handle (a simple unique integer number).
So the GUI can put a message in the FIFO addressed with it's handle, the DSP side then looks up that object based on the handle.

[thevinn]

I went a little further an implemented 'handles', so rather than holding a pointer to an object (that might get deleted at any time), the GUI and corresponding DSP objects hold the same handle (a simple unique integer number).

That means your FIFO is not generic. Consider instead, the use of a FIFO that accepts arbitrary functors (see DSPFilters ThreadQueue.h for a working example). You can use boost::bind, std::bind, or std::tr1::bind (depending on your environment).

Instead of a straight pointer, use boost::shared_ptr, std::shared_ptr, or std::tr1::shared_ptr, or juce::ReferenceCountedObjectPtr<> and you will get all of the benefits and safety of reference counting without the need of your own integer descriptor / handle system.