in reply to loss of dll in a multi threaded app

As a temporary fix, why not just put "finished threads" to sleep, and reuse them for the future "accepts"? It would probably be more efficient too, rather than constantly creating new threads. (But I think your problem is windows.. :-) )

I'm not really a human, but I play one on earth. flash japh
  • Comment on Re: loss of dll in a multi threaded app

Replies are listed 'Best First'.
Re^2: loss of dll in a multi threaded app
by jwetherill (Initiate) on Jul 04, 2005 at 16:39 UTC
    could you give me a short example of reuseing the threads, as I have not seen any.

      Apache uses that model. It starts up a number of web server processes. When a request comes in, the main process forwards the request to one of the idle child processes*. It handles the request then waits to be asked to process another.

      * I think this is optimized such that the implementation -- but not the effect -- differs from the above explanation.

      a trick would be to give each worker thread a shared "control" variable that is only used by that thread and the main thread. The main thread takes a lock on the variable, and the worker thread then tries to take a lock on it as well, which will block(put the thread to sleep) until the main thread uses cond_signal(part of threads::shared) to release the lock and hence wake up the worker thread. One might even configure said control variable to contain something useful, ie a filehandle that the worker thread needs to start working on.


      Remember rule one...
      The hash variables below are used so I can have multiple threads waiting in a sleep state for use. The trick to using threads this way, is knowing that they must go to the end of their code block, before joining them. 'go' = 1 wakes them from sleep, and 'die' = 1 signals them to prepare to be joined. It's basically a sleep loop, which wakes up every second, and see's if there is anything to do, or if it's time to die. When done with it's task, it just goes back to sleep. If you know how many max threads you need, you can pre-create them, and track them in some sort of "free-pool", so when you need a thread, it can shift one off of the free-pool-array, and when a thread is finished, push it onto the free-pool-array.

      See Tk-with-worker-threads and Threads-w-Perl/Gtk2 demo for full working examples.

      sub work{ my $dthread = shift; $|++; while(1){ if($shash{$dthread}{'die'} == 1){ goto END }; if ( $shash{$dthread}{'go'} == 1 ){ #in case I want to pass it code for evaling eval( system( $shash{$dthread}{'data'} ) ); # a simple little task foreach my $num (1..100){ $shash{$dthread}{'progress'} = $num; print "\t" x $dthread,"$dthread->$num\n"; select(undef,undef,undef, .5); if($shash{$dthread}{'go'} == 0){last} if($shash{$dthread}{'die'} == 1){ goto END }; } $shash{$dthread}{'go'} = 0; #turn off self before returning }else { sleep 1 } } END: }

      I'm not really a human, but I play one on earth. flash japh