Assorted changes for multi-threading (now works rather more).
[p5sagit/p5-mst-13.2.git] / README.threads
CommitLineData
0f15f207 1Some old globals (e.g. stack_sp, op) and some old per-interpreter
2variables (e.g. tmps_stack, cxstack) move into struct thread.
3All fields of struct thread (apart from a few only applicable to
4FAKE_THREADS) are of the form Tfoo. For example, stack_sp becomes
5the field Tstack_sp of struct thread. For those fields which moved
6from original perl, thread.h does
7 #define foo (thr->Tfoo)
8This means that all functions in perl which need to use one of these
9fields need an (automatic) variable thr which points at the current
10thread's struct thread. For pp_foo functions, it is passed around as
11an argument, for other functions they do
12 dTHR;
13which declares and initialises thr from thread-specific data
14via pthread_getspecific. If a function fails to compile with an
15error about "no such variable thr", it probably just needs a dTHR
16at the top.
17
18For FAKE_THREADS, thr is a global variable and perl schedules threads
19by altering thr in between appropriate ops. The next and prev fields
20of struct thread keep all fake threads on a doubly linked list and
21the next_run and prev_run fields keep all runnable threads on a
22doubly linked list. Mutexes are stubs for FAKE_THREADS. Condition
23variables are implemented as a list of waiting threads.
24
25
26Mutexes and condition variables
27
28The API is via macros MUTEX_{INIT,LOCK,UNLOCK,DESTROY} and
29COND_{INIT,WAIT,SIGNAL,BROADCAST,DESTROY}. For POSIX threads,
30perl mutexes and condition variables correspond to POSIX ones.
31For FAKE_THREADS, mutexes are stubs and condition variables are
32implmented as lists of waiting threads. For FAKE_THREADS, a thread
33waits on a condition variable by removing itself from the runnable
34list, calling SCHEDULE to change thr to the next appropriate
35runnable thread and returning op (i.e. the new threads next op).
36This means that fake threads can only block while in PP code.
37A PP function which contains a COND_WAIT must be prepared to
38handle such restarts and can use the field "private" of struct
39thread to record its state. For fake threads, COND_SIGNAL and
40COND_BROADCAST work by putting back all the threads on the
41condition variables list into the run queue. Note that a mutex
42must *not* be held while returning from a PP function.
43
44Perl locks are a condpair_t structure (a triple of a mutex, a
45condtion variable and an owner thread field) attached by 'm'
46magic to any SV. pp_lock locks such an object by waiting on the
47condition variable until the owner field is zero and then setting
48the owner field to its own thread pointer. The lock is recursive
49so if the owner field already matches the current thread then
50pp_lock returns straight away. If the owner field has to be filled
51in then unlock_condpair is queued as an end-of-block destructor and
52that function zeroes out the owner field, releasing the lock.