0

I'm trying to figure out a way to put some thread in a passive waiting mode and wake them up as they arrive to the barrier. I have a fixed amount of thread that should arrive.

I was first thinking about a semaphore that i would initialise at 0 so it would block but they will be released in a random way. I would like to implement a system that would release the thread in the order the came to the barrier of synchronisation like a FIFO.

I also thought about using 2 semaphore, on that would block, release a thread and sort it. If the thread is the good one then it just goes, if not then it's blocked by the second semaphore. However this system seems kind of long and fastidious.

Does someone have an idea or suggestions that would help me ?

Thank you very much :)

MaxUt
  • 127
  • 8
  • 'I would like' - is that a firm requirement? If not, it's avoidable messiness. In general, enforcing an order, such as you suggest, is a design that is best avoided. It can be done, but since any thread X that is released from the barrier may be preempted ny thread X+1 that is released immediately afterwards, your 'like' is not really enforceable or useful. – Martin James Nov 30 '17 at 14:17
  • I mean, if you really need to make a lot of extra syscalls that provide no guarantees and negligible advantage, have them all enter a CS and all except the last get a semaphore, put the sema into a queue container, exit the CS and block on the sema. When the last thread enters,.it can dequeue the semaphores, signal them in order, exit the CS itself and carry on. – Martin James Nov 30 '17 at 14:23
  • Re, "put some thread in a passive waiting mode and wake them up as they arrive to the barrier." That makes no sense. A thread will never "arrive at a barrier" as long as it is passively waiting for something. Normally, when you say "barrier," you're talking about a situation where "arriving at the barrier" is what causes the thread to wait. – Solomon Slow Nov 30 '17 at 14:29
  • I guess the worst case is that there are no free cores when the last thread enters the lock and finds out that it is the last:) It signals all the semaphores in order, making all the other threads ready, but they aren't set running because there are no cores free. The last thread then exits the CS and ends up running first. – Martin James Nov 30 '17 at 14:29
  • @jameslarge yes, it's all a bit umm... 'fuzzy'. These sorts of requirements are not 'real'. They are dreamed up by profs/TA's during Friday afternoon tequila sessions. They have no real application because they provide no guarantees, just a sorta tendency. A sane design would just block them all on some event and set them all going at once, letting the scheduling fall where it may, as it will anyway:). – Martin James Nov 30 '17 at 14:35
  • 1
    [X Y Problem?](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) _Why_ do you want the threads to behave in this way? Any attempt to so closely couple the behavior of threads is bound to be an inefficient and/or clumsy solution to your problem. What _is_ the problem that you really are trying to solve? – Solomon Slow Nov 30 '17 at 14:35
  • @MaxUt Your description sounds a lot like a Ticket Lock - see e.g. https://stackoverflow.com/questions/5385777/implementing-a-fifo-mutex-in-pthreads – binary01 Nov 30 '17 at 16:21
  • It's an assignment that's why it doesn't make sense aha. So each thread is supposed to represent some clients. There are a fix number of 'seats' for these clients. They have to 'wait' in a passive way to not consume CPU. On the other hand there are other thread considered as tattoo artist, when a thread is free or asleep then a thread client is release, or do a sem_post on the semaphore of the tatoo artists to release one. The only problem is that the client must leave the waiting stage in the order they came, like in a queue. Thank you all anyway for your tips :) – MaxUt Dec 01 '17 at 09:51

1 Answers1

0

On Linux, you can just use a condition variable and a mutex to block and unblock threads in the same FIFO order.

This is because all waiters on a condition variable append to the futex wait queue in the kernel in order. Waking up the waiters happens in the same FIFO order. As long as you keep the mutex locked while signaling the condition variable.

However, as commenters mentioned, this is a poor idea to depend on thread execution order.

Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
  • Thank you. I agree it's not efficient. It's actually an assignment i have. Each thread is supposed to represent a client in a waiting room. So it must not use CPU ressources during the waiting time. Each client must be released in the order he arrived. – MaxUt Dec 01 '17 at 13:21