There is a high risk of deadlocks with pthread_barrier_wait because it requires an exact number of threads to wait before any of them can continue.
So, I'm not sure if I want to implement this. If that sort of parallelization is needed, perhaps that should be fully encapsulated in a C++ extension that divides up work in a particular manner.
The only situation I recall using a barrier in was to wait for all processing threads to be ready prior to reading very large amounts of data from disk for the next block of processing. So, it definitely has its uses, but I don't know if that sort of use-case will be common in Zeolite code.
Perhaps there's a way to make it less prone to deadlocks.
For example:
Have a "setup" state for the barrier, where each thread gets a proxy object to use for blocking. After that, "lock in" the number of proxies and create the barrier. (Thread count determines barrier expectation.)
Create n proxies upon construction and return them in a ReadAt. Since they will need to be retrieved by index, that implies that the threads will also need to be enumerated in order for each to have its own proxy. (Barrier expectation determines thread count.)
There is a high risk of deadlocks with
pthread_barrier_waitbecause it requires an exact number of threads to wait before any of them can continue.So, I'm not sure if I want to implement this. If that sort of parallelization is needed, perhaps that should be fully encapsulated in a C++ extension that divides up work in a particular manner.
The only situation I recall using a barrier in was to wait for all processing threads to be ready prior to reading very large amounts of data from disk for the next block of processing. So, it definitely has its uses, but I don't know if that sort of use-case will be common in Zeolite code.
Perhaps there's a way to make it less prone to deadlocks.
For example:
nproxies upon construction and return them in aReadAt. Since they will need to be retrieved by index, that implies that the threads will also need to be enumerated in order for each to have its own proxy. (Barrier expectation determines thread count.)