Question

I have the following situation: I have two threads

• thread1, which is a worker thread that executes an algorithm until its input list size is > 0
• thread2, which is asynchronous (user driven) and can add elements to the input list to be processed

Now, thread1 loop does something similar to the following

list input_list
list buffer_list

if (input_list.size() == 0)
  sleep

while (input_list.size() > 0) {
  for (item in input_list) {
    process(item);
    possibly add items to buffer_list
  }
  input_list = buffer_list (or copy it)
  buffer_list = new list (or empty it)
  sleep X ms (100 < X < 500, still have to decide)
}

Now thread2 will just add elements to buffer_list (which will be the next pass of the algorithm) and possibly manage to awake thread1 if it was stopped.

I’m trying to understand which multithread issues can occur in this situation, assuming that I’m programming it into C++ with aid of STL (no assumption on thread-safety of the implementation), and I have of course access to standard library (like mutex).

I would like to avoid any possible delay with thread2, since it’s bound to user interface and it would create delays. I was thinking about using 3 lists to avoid synchronization issues but I’m not real sure so far. I’m still unsure either if there is a safer container within STL according to this specific situation.. I don’t want to just place a mutex outside everything and lose so much performance.

Any advice would be very appreciated, thanks!

EDIT:

This is what I managed so far, wondering if it’s thread safe and enough efficient:

std::set<Item> *extBuffer, *innBuffer, *actBuffer;

void thread1Function()
{
  actBuffer->clear();
  sem_wait(&mutex);
  if (!extBuffer->empty())
    std::swap(actBuffer, extBuffer);
  sem_post(&mutex);
  if (!innBuffer->empty())
  {
    if (actBuffer->empty())
      std::swap(innBuffer, actBuffer);
    else if (!innBuffer->empty())
      actBuffer->insert(innBuffer->begin(), innBuffer->end());
  }

  if (!actBuffer->empty())
  {
    set<Item>::iterator it;
    for (it = actBuffer.begin; it != actBuffer.end(); ++it)
      // process
      // possibly innBuffer->insert(...)
  }
}

void thread2Add(Item item)
{
  sem_wait(&mutex);
  extBuffer->insert(item);
  sem_post(&mutex);

}

Probably I should open another question

Answer 1

If you are worried about thread2 being blocked for a long time because thread1 is holding on to the lock, then make sure that thread1 guarentees to only take the lock for a really short time.

This can be easily accomplished if you have two instances of buffer list. So your attempt is already in the right direction.

Each buffer is pointed to with a pointer. One pointer you use to insert items into the list (thread2) and the other pointer is used to process the items in the other list (thread1). The insert operation of thread2 must be surrounded by a lock.

If thread1 is done processing all the items it only has to swap the pointers (e.g. with std::swap) this is a very quick operation which must be surrounded by a lock. Only the swap operation though. The actual processing of the items is lock-free.

This solution has the following advantages:

1. The lock in thread1 is always very short, so the amount of time that it may block thread2 is minimal
2. No constant dynamic allocation of buffers, which is faster and less likely to cause memory leak bugs.