1933.1.9
by Brian Aker
Additional documentation and testing. |
1 |
User Defined Barriers
|
2 |
=====================
|
|
3 |
||
4 |
SELECT create_barrier(); |
|
5 |
||
6 |
SELECT release_barrier(); |
|
7 |
||
8 |
SELECT wait(); |
|
9 |
||
10 |
SELECT wait_until(); |
|
11 |
||
12 |
SELECT signal(); |
|
13 |
||
14 |
A barrier is a synchronization objest which can be used to syncronize a |
|
15 |
group of session to a specific rendezvous by calling wait(). At which point |
|
16 |
any session of the user may call signal() and all sessions being held by wait() are allowed to proceed. |
|
17 |
||
18 |
Barriers can optional be created with a limit so that once a set number of sessions have called wait() that all "waiters" are then allowed to proceed. |
|
19 |
||
20 |
The session that creates the barrier via create_barrier() is not allowed to |
|
21 |
call either wait() or wait_until(). |
|
22 |
||
23 |
The scope of barriers is to the given username. |
|
24 |
||
25 |
Beyond waiters, you can also create observers by using the wait_until() |
|
26 |
function. Observers are released not only when signal() or release_barrier() |
|
27 |
is called, but also when their definitine predicate happens. You can use |
|
28 |
wait_until() to have a session wait for a certain number of waiters to |
|
29 |
occur, and then do some body of work before the waiters() are signalled to |
|
30 |
continue. |
|
31 |
||
32 |
All waiters and observers are released if release_barrier() is called by the |
|
33 |
session which created the barrier. Also, if the session that created the |
|
34 |
barrier disconnects, all waiters and observers are notified. |
|
35 |
||
36 |
Information on all barriers can be found in the DATA_DICTIONARY.USER_BARRIERS |
|
37 |
table; |