What is KVR Audio? | Submit News | Advertise | Developer Account

Options (Affects News & Product results only):

OS:
Format:
Include:
Quick Search KVR

"Quick Search" KVR Audio's Product Database, News Items, Developer Listings, Forum Topics and videos here. For advanced Product Database searching please use the full product search. For the forum you can use the phpBB forum search.

To utilize the power of Google you can use the integrated Google Site Search.

Products 0

Developers 0

News 0

Forum 0

Videos 0

Search  

Reading - modifying vector from different threads.

DSP, Plug-in and Host development discussion.

Moderator: Moderators (Main)

KVRist
 
202 posts since 11 Feb, 2009, from Perú
 

Postby Tzarls; Sat Feb 25, 2012 4:32 pm

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.
KVRer
 
5 posts since 9 Jun, 2004

Postby zman; Sun Feb 26, 2012 11:35 am

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.
KVRist
 
202 posts since 11 Feb, 2009, from Perú
 

Postby Tzarls; Tue Mar 13, 2012 9:12 am

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. :)
User avatar
KVRAF
 
8978 posts since 7 Dec, 2004, from Vancouver, Canada
 

Postby aciddose; Tue Mar 13, 2012 9:14 am

KVRian
 
767 posts since 30 Nov, 2008
 

Postby thevinn; Tue Mar 13, 2012 9:29 am

Tzarls wrote: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
KVRist
 
254 posts since 30 Jan, 2005, from New Zealand
 

Postby Jeff McClintock; Tue Mar 13, 2012 11:38 am

Tzarls wrote: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.
KVRian
 
767 posts since 30 Nov, 2008
 

Postby thevinn; Tue Mar 13, 2012 11:42 am

Jeff McClintock wrote: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.
Previous

Moderator: Moderators (Main)

Return to DSP and Plug-in Development