Re: Thread initialization and condition

[Joaquim Duran <joaquinduran adtelecom es>]

En/na Andreas Volz ha escrit:
> 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
>   }
> }

I think that the problem is that a thread to wait in a condition, the
thread should have locked the mutex. Could you check that?

> 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.
> 

You should assume nothing about mutex: this is executed before that
functions or not, or this code is longer that another function. OS is
managing the mutex and if the OS changes the scheduling police (or what
else) then the code is working or not.

You should create a synchronization police that is able to run in any
situation (no assume anything about scheduler).

Joaquim Duran
Thanks and Best Regards,