Add pthread_barrier event #35
Conversation
bjackman
force-pushed
the
pthread-barrier
branch
7 times, most recently
from
11d2f7c to
fc23d7e
Compare
|
Internally, @derkling suggested that the name for the existing event be changed, I guess 'cond_barrier' would be a natural name, but @deggeman pointed out that 'barrier' is in v1.0 so it can't be removed, but we could deprecate the name 'barrier', what do you think @vingu-linaro and @jlelli ? |
|
Oh also cc: @credp who did the 'barrier' event |
This is just like the barrier event except it actually uses pthread_barrier_wait instead of pthread_cond_wait and pthread_cond_broadcast. This alternative method may cause issues with killing rt-app, but is still desirable because it exercises different syscall usage patterns, which are used in real workloads. I have tried to explain the details of this in tutorial.txt Implementing this requires adding a `finalize` step to resource setup, because we need to know the number of threads that refer to the resource before we can call pthread_barrier_init.
bjackman
force-pushed
the
pthread-barrier
branch
from
fc23d7e to
1d1befc
Compare
|
Ping? |
|
Just spoke with @vingu-linaro, he said that this would be better implemented using a single event rather than having two separate events - at least in the JSON grammar (even if it is implemented internally as a separate event). This is basically all about testing this kernel patch, which has not generated any interest from maintainers and since I am leaving Arm soon, has no immediate future. Therefore it looks like this PR will hang around for a while longer. |
|
Let if someone else can take over your patchset to do the changes |
|
I am in favour of keeping this PR open but I don't have time to pick it up myself right now. |
+1 |
This is just like the barrier event except it actually uses
pthread_barrier_wait instead of pthread_cond_wait and
pthread_cond_broadcast. This alternative method may cause issues with
killing rt-app, but is still desirable because it exercises different
syscall usage patterns, which are used in real workloads. I have
tried to explain the details of this in tutorial.txt
Implementing this requires adding a
finalizestep to resourcesetup, because we need to know the number of threads that refer to
the resource before we can call pthread_barrier_init.