@kevinle1 Say there are n threads arrived and the barrier is removed, so that they can proceed. However some of them experience some delay due to OS scheduling or something else, they haven't proceed but there are threads who proceed in advance and invoke barrier method again.
In this situation, the threads that haven't got out of last-round barrier locked, and threads that newly hit the barrier locked as well since the num_arrived will never reach p.
Split_Personality_Computer
@autumnust In this kind of situation though couldn't you just declare multiple barriers to prevent this from happening? As in everyone gets to barrier A, then everyone gets to barrier B, then barrier A can be reused after this? Or is the goal to be able to do everything in one barrier
hanzhoul
I have the same doubt. Why do we only use one barrier for all of these synchronizations?
Can someone explain why this doesn't work again?
@kevinle1 Say there are n threads arrived and the barrier is removed, so that they can proceed. However some of them experience some delay due to OS scheduling or something else, they haven't proceed but there are threads who proceed in advance and invoke barrier method again.
In this situation, the threads that haven't got out of last-round barrier locked, and threads that newly hit the barrier locked as well since the num_arrived will never reach p.
@autumnust In this kind of situation though couldn't you just declare multiple barriers to prevent this from happening? As in everyone gets to barrier A, then everyone gets to barrier B, then barrier A can be reused after this? Or is the goal to be able to do everything in one barrier
I have the same doubt. Why do we only use one barrier for all of these synchronizations?