views:

100

answers:

4

hi all,

i have a question about thread situation.

Suppose i have 3 threads :producer,helper and consumer. the producer thread is in running state(and other two are in waiting state)and when its done it calls invoke,but the problem it has to invoke only helper thread not consumer,then how it can make sure that after it releases resources are to be fetched by helper thread only and then by consumer thread.

thanks in advance

+1  A: 

You could have, for instance, two mutexes (or whatever you are using): one for producer and helper, and other for producer and consumer

Producer:
  //lock helper
     while true
  {
   //lock consumer
   //do stuff
   //release and invoke helper
   //wait for helper to release
   //lock helper again
   //unlock consumer
   //wait consumer
  }

The others just lock and unlock normally.

Another possible approach (maybe better) is using a mutex for producer / helper, and other helper / consumer; or maybe distribute this helper thread tasks between the other two threads. Could you give more details?

Samuel Carrijo
Change 'mutex' to be 'event' or 'signal', and this is a good suggestion. Waiting for a semaphor to be signaled is a typical way to setup wait states between threads. It doesn't ensure thread-safety of the shared data, but that's a different problem.
Kieveli
+1  A: 

The helper thread is really just a consumer/producer thread itself. Write some code for the helper like you would for any other consumer to take the result of the producer. Once that's complete write some code for the helper like you would for any other producer and hook it up to your consumer thread.

Spencer Ruport
+2  A: 

Or have you considered, sometimes having separate threads is more of a problem than a solution?

If you really want the operations in one thread to be strictly serialized with the operations in another thread, perhaps the simpler solution is to discard the second thread and structure the code so the first thread does the operations in the order desired.

This may not always be possible, but it's something to bear in mind.

JustJeff
+1 because the question does appear to need things to be done in serial rather than in parallel; in that case, threads are just overkill, a hammer looking for a nail.
mmr
Good insight - the problem is that a procedural programmer is doing multi-threading for the first time, and still making his software designed to run in serial, but in multiple threads. Interesting.
Kieveli
+1  A: 

You might be able to use queues to help you with this with locks around them. Producer works on something, produces it, and puts it on the helper queue. Helper takes it, does something with it, and then puts it on the consumer queue. Consumer take its, consumes it, and goes on.

Something like this:

Queue<MyDataType> helperQ, consumerQ;
object hqLock = new object();
object cqLock = new object();

// producer thread
private void ProducerThreadFunc()
{
    while(true)
    {
        MyDataType data = ProduceNewData();
        lock(hqLock)
        {
            helperQ.Enqueue(data);
        }
    }
}

// helper thread
private void HelperThreadFunc()
{
    while(true)
    {           
        MyDataType data;
        lock(hqLock)
        {
            data = helperQ.Dequeue();
        }

        data = HelpData(data);
        lock(cqLock)
        {
            consumerQ.Enqueue(data);
        }
    }
}

// consumer thread
private void ConsumerThreadFunc()
{
    while(true)
    {           
        MyDataType data;
        lock(cqLock)
        {
            data = consumerQ.Dequeue();
        }            
        Consume(data);            
    }
}

NOTE: You will need to add more logic to this example to make sure usable. Don't expect it to work as-is. Mainly, use signals for one thread to let the other know that data is available in its queue (or as a worst case poll the size of the queue to make sure it is greater than 0 , if it is 0, then sleep -- but the signals are cleaner and more efficient).

This approach would let you process data at different rates (which can lead to memory issues).

Erich Mirabal