diff options
author | Anand Avati <avati@redhat.com> | 2013-02-21 00:17:26 -0800 |
---|---|---|
committer | Anand Avati <avati@redhat.com> | 2013-02-21 22:57:04 -0800 |
commit | 72ad9a3a8b684595dc394252c88c76c859919a45 (patch) | |
tree | ef6eb57e7d817b9bf3f8f942ea9ba137cd61d16f /libglusterfs/src/event-epoll.c | |
parent | 1dbe9a05feac5032990457058f7cef686a293973 (diff) |
synctask: support for (assymetric) counted barriers
This patch introduces a new set of primitives:
- synctask_barrier_init (stub)
- synctask_barrier_waitfor (stub, count)
- synctask_barrier_wake (stub)
Unlike pthread_barrier_t, this barrier has an explicit notion of
"waiter" and "waker". The "waiter" waits for @count number of
"wakers" to call synctask_barrier_wake() before returning. The
wait performed by the waiter via synctask_barrier_waitfor() is
co-operative in nature and yields the thread for scheduling other
synctasks in the mean time.
Intended use case:
Eliminate excessive serialization in glusterd and allow for
concurrent RPC transactions.
Code which are currently in this format:
---old---
list_for_each_entry (peerinfo, peers, op_peers_list) {
...
GD_SYNCOP (peerinfo->rpc, stub, rpc_cbk, ...);
}
...
int rpc_cbk (rpc, stub, ...)
{
...
__wake (stub);
}
---old---
Can be restructred into the format:
---new---
synctask_barrier_init (stub);
{
list_for_each_entry (peerinfo, peers, op_peers_list) {
...
rpc_submit (peerinfo->rpc, stub, rpc_cbk, ...);
count++;
}
}
synctask_barrier_wait (stub, count);
...
int rpc_cbk (rpc, stub, ...)
{
...
synctask_barrier_wake (stub);
}
---new---
In the above structure, from the synctask's point of view, the region
between synctask_barrier_init() and synctask_barrier_wait() are spawning
off asynchronous "threads" (or RPC) and keep count of how many such
threads have been spawned. Each of those threads are expected to make
one call to synctask_barrier_wake(). The call to synctask_barrier_wait()
makes the synctask thread co-operatively wait/sleep till @count such threads
call their wake function.
This way, the synctask thread retains the "synchronous" flow in the code,
yet at the same time allows for asynchronous "threads" to acheive parallelism
over RPC.
Change-Id: Ie037f99b2d306b71e63e3a56353daec06fb0bf41
BUG: 913662
Signed-off-by: Anand Avati <avati@redhat.com>
Reviewed-on: http://review.gluster.org/4558
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Tested-by: Krishnan Parthasarathi <kparthas@redhat.com>
Diffstat (limited to 'libglusterfs/src/event-epoll.c')
0 files changed, 0 insertions, 0 deletions