Re: Signals in threads

[Paul Davis <paul linuxaudiosystems com>]

On Thu, 2006-06-22 at 09:21 -0400, Dave Foster wrote:
> Hmm, I know I replied to this last night, perhaps I forgot to do reply 
> all.  Bob basically said what I did as well, however...
> 
> Bob Caryl wrote:
> >
> > In my case, I had also declared in my GUI class a 
> > std::vector<Glib::ustring> object to which my worker thread pushed 
> > back string data that I wanted to add to a Gtk::TextBuffer displayed 
> > in a Gtk::TextView in my GUI class.  My callback slot would pop the 
> > Glib::ustrings off this vector one at a time and add them to the 
> > Gtk::TextBuffer whenever it was called by the dispatcher.  Therefore, 
> > my worker thread would push back strings to this vector object just 
> > prior to calling the dispatcher.
> Your std::vector method does not sound very thread-safe.. there can be 
> interleaving issues if your worker thread were to push a string on as 
> your consumer thread were to pop strings off.  Two solutions to this:  
> use a mutex around accesses to your vector (gtkmm has a nice 
> auto-destructing one), or use something which is already thread-safe 
> like g_async_queue (or w/e that name is, i can't seem to remember it).

single-reader/single-writer queues are inherently thread-safe as long as
you are sensible about their implementation. lock-free ringbuffers are a
widely used technique in realtime programming. JACK
(http://jackaudio.org/) has a sample C implementation. i would agree,
however, that using std::vector<Glib::ustring> is not thread safe.

--p