Re: Thread initialization and condition

[Joaquim Duran <joaquinduran adtelecom es>]

Hello,

Andreas told in his previous email the he was already using a queue. The
code to synchronize the thread should be similar to (pseucode):

Main thread:

Push a new file to queue (assuming STL like queue):
mutex.lock()
queue.push(fine_name);
condition.signal();
mutex.unlock();


Stop a Job:
mutex.lock();
stop= true;
condition.signal();
mutex.unlock();

FTP Thread:

Get a file fro queue :

string fname;

mutex.lock();
while ((!stop) && (queue.empty())
{
	condition.wait();	
}
if (stop)
{
	mutex.unlock();
	exit_thread();
}

fname = queue.top();
mutex.unlock();
return fname;


En/na Naveen Verma ha escrit:
> Hi,
> 
> I also tried the similar and very simple program on Ubuntu, and find
> similar behavior. It seems that thread creation takes longer time,  and
> we call the other member function i.e. fetch() before that. I did
> nothing but just printing the debug logs and log in fetch() print before
> that the loop().
> 
> And the same behavior with pthread also. May be thread creation and
> execution time varies between different OS and CPU?
> 
> May be we can have a queue between threads, one thread put the requests
> in queue and other thread reads and process from that?
> 
> 
> -Br
> Naveen
> 
> On Jan 4, 2008 3:06 PM, Joaquim Duran <joaquinduran adtelecom es
> <mailto:joaquinduran adtelecom es>> wrote:
> 
>     En/na Andreas Volz ha escrit:
>     > Hello,
>     >
>     > I have a problem while running a thread application. Here is my code:
>     >
>     > Download::Download ()
>     > {
>     >   thread = Glib::Thread::create (sigc::mem_fun (*this,
>     >            &Download::threadFunc), true);
>     > }
>     >
>     > void Download::fetch ()
>     > {
>     >   // queue new files to download...
>     > }
>     >
>     > void Download::loop ()
>     > {
>     >   do
>     >   {
>     >     // download new files
>     >   }
>     >   while (1)
>     > }
>     >
>     > Ok, this was working on one machine. But now while testing it on
>     > another machine (also Linux) I got other results. This is how I
>     use it:
>     >
>     >   Download dl;
>     >   dl.fetch (m_url, m_file);
>     >
>     > If I do debugging or print some debug messages I see that on one
>     > machine the thread loop() is entered before the fetch() function. I
>     > would expect that. But on the other machine the fetch() function is
>     > called before the thread loop().
>     >
>     > Couldn't I trust gtkmm that the thread loop is constructed and entered
>     > after returning the Glib::Thread::create() call?
>     >
>     > 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.
>     >
>     > Gentoo:
>     > - gtkmm-2.10.10
>     > - thread loop() is called *before* fetch()
>     >
>     > Ubuntu:
>     > - libgtkmm-2.4-1c2a 1:2.12.0-0ubuntu1
>     > - thread loop() is called *after* fetch()
>     >
>     > Any ideas about that problem?
>     >
>     > regards
>     > Andreas
>     > _______________________________________________
>     > gtkmm-list mailing list
>     > gtkmm-list gnome org <mailto:gtkmm-list gnome org>
>     > http://mail.gnome.org/mailman/listinfo/gtkmm-list
>     >
>     >
> 
>     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.
> 
>     Joaquim Duran
>     Thanks and Best Regards,
>     _______________________________________________
>     gtkmm-list mailing list
>     gtkmm-list gnome org <mailto:gtkmm-list gnome org>
>     http://mail.gnome.org/mailman/listinfo/gtkmm-list
>     <http://mail.gnome.org/mailman/listinfo/gtkmm-list>
> 
>