Re: Thread initialization and condition

[Andreas Volz <lists brachttal net>]

Am Fri, 04 Jan 2008 14:06:43 +0100 schrieb Joaquim Duran:

> > I tried to use some conditions to wait until the thread has
> > entered. It worked, but only on one machine. The other one blocked
> > forever. If this is a defined behaviour that I need to think about
> > a more complex condition mechanism at initialization time.
> >
> This looks like that there is no synchronization between main thread
> and the FTP thread. The FTP thread should be waiting till main thread
> has posted a new file to download and then start download.
> 
> GLibmm provides mutex and mutex-conditions to implement a
> producer-consumer relation between threads.

Sure there's no synchronisation in this example code. But in my
application is a synchronisation. I only deleted that to ease the
example. My question was the order and time of thread creation.

Here again with synchronisation:

Download::Download ()
{
  threadState.thread = Glib::Thread::create (sigc::mem_fun (*this,
                       &Download::threadFunc), true);
  ...
}

void Download::fetch (const string &url, const string &filename)
{
  // queue new download file
  
  threadState.condDl.signal(); 
}

void Download::threadFunc ()
{
  while (threadState.running)
  {
    threadState.condDl.wait (threadState.mutexDl);
    
    if (!threadState.running)
    {
      // leave download loop if thread state is not longer running
      // while waiting for new downloads
      break;
    }

    // download new file here
  }
}

On Gentoo this code works great because the threadFunc() is called
before the first fetch(). In this situation the thread starts and waits
in front of the download code in the loop each time a new fetch() call
arrives. So this looks good in my eyes.

But on Ubuntu the fetch() is called before the threadFunc(). Then it
sends the signal to early. If the threadFunc() then starts (too late)
it waits an infinite time on the (too early) arrived signal.

So I have two different behaviour of the same code on two machines. For
me the locking in this example looks fine. But maybe I've done a
mistake.

So the question is if it's a defined behaviour that threadFunc() could
be called after fetch()?

regards
Andreas