is there any way to wakeup multiple threads at the same time in c/c-CodePudding

well, actually, I'm not asking the threads must "line up" to work, but I just want to notify multiple threads. so I'm not looking for barrier. it's kind of like the condition_variable::notify_all(), but I don't want the threads wakeup one-by-one, which may cause starvation(also the potential problem in multiple semaphore post operation). it's kind of like:

std::atomic_flag flag{ATOMIC_FLAG_INIT};
void example() {
    if (!flag.test_and_set()) {
//  this is the thread to do the job, and notify others
        do_something();
        notify_others(); // this is what I'm looking for
    } else {
//  this is the waiting thread
        wait_till_notification();
        do_some_other_thing();
    }
}

void runner() {
    std::vector<std::threads>;
    for (int i=0; i<10;   i) {
        threads.emplace_back([]() {
        while(1) {
            example();
        }
    });
    }
// ...
}
so how can I do this in c/c   or maybe posix API?

CodePudding user response：

It sounds like you are looking for call_once

#include <mutex>

void example()
{
  static std::once_flag flag;
  bool i_did_once = false;
  std::call_once(flag, [&i_did_once]() mutable {
    i_did_once = true;
    do_something();
  });
  if(! i_did_once)
    do_some_other_thing();
}

I don't see how your problem relates to starvation. Are you perhaps thinking about the thundering herd problem? This may arise if do_some_other_thing has a mutex but in that case you have to describe your problem in more detail.

CodePudding user response：

it's kind of like the condition_variable::notify_all(), but I don't want the threads wakeup one-by-one, which may cause starvation

In principle it's not waking up that is serialized, but re-acquiring the lock.

You can avoid that by using std::condition_variable_any with a std::shared_lock - so long as nobody ever gets an exclusive lock on the std::shared_mutex. Alternatively, you can provide your own Lockable type.

Note however that this won't magically allow you to concurrently run more threads than you have cores, or force the scheduler to start them all running in parallel. They'll just be marked as runnable and scheduled as normal - this only fixes the avoidable serialization in your own code.