A flexible, lightweight, spin-lock barrier

Re:A flexible, lightweight, spin-lock barrier by atq2119 on Tuesday March 15, 2022 @01:38PM (#30688335)

It's a nice write up. I did this once with a slight modification. The phase really only needs one bit, and an arbitrary number of threads can be supported in a number of ways by having the last thread to arrive at the barrier clean up the state based on a second word that holds the number of threads.

For example, compare the thread counter part of the "v" value to the number of threads. If equal, do an atomic store which writes the opposite phase with a thread count of 0. If not equal, spin until the phase bit changes.

This approach avoids a division and can support threads that leave the barrier entirely. (And theoretically also entering the barrier, but that's always dicey regardless of the barrier implementation.)

[ Parent | on HN ]

Re:A flexible, lightweight, spin-lock barrier by gpderetta on Tuesday March 15, 2022 @03:13PM (#30689848)

So, I understand that the difficulty is being able to reset the barrier without a quiescent period.

It seems to me that a counter being able to count to n is enough and there is no need of an explicit phase bit:

  Wait(int *b, int n):
     1: x = *b
     if (x == n-1)
        *b=0 //last, reset
     else if cas(b, x, x+1)
         2: if *b goto 2
     else goto 1

[ Parent | on HN ]

Re:A flexible, lightweight, spin-lock barrier by atq2119 on Tuesday March 15, 2022 @04:36PM (#30691264)

Your spin loop could easily miss the time during which *b == 0. The article explains that. A separate phase bit is required.

[ Parent | on HN ]

Re:A flexible, lightweight, spin-lock barrier by gpderetta on Tuesday March 15, 2022 @04:43PM (#30691384)

Yes. I see it now.

[ Parent | on HN ]