Warning: This is the manual of the legacy Guile 2.0 series. You may want to read the manual of the current stable series instead.
Next: Fluids and Dynamic States, Previous: Blocking, Up: Scheduling [Contents][Index]
These two macros can be used to delimit a critical section. Syntactically, they are both statements and need to be followed immediately by a semicolon.
Executing SCM_CRITICAL_SECTION_START
will lock a recursive
mutex and block the executing of system asyncs. Executing
SCM_CRITICAL_SECTION_END
will unblock the execution of system
asyncs and unlock the mutex. Thus, the code that executes between
these two macros can only be executed in one thread at any one time
and no system asyncs will run. However, because the mutex is a
recursive one, the code might still be reentered by the same thread.
You must either allow for this or avoid it, both by careful coding.
On the other hand, critical sections delimited with these macros can be nested since the mutex is recursive.
You must make sure that for each SCM_CRITICAL_SECTION_START
,
the corresponding SCM_CRITICAL_SECTION_END
is always executed.
This means that no non-local exit (such as a signalled error) might
happen, for example.
Call scm_dynwind_lock_mutex
on mutex and call
scm_dynwind_block_asyncs
. When mutex is false, a recursive
mutex provided by Guile is used instead.
The effect of a call to scm_dynwind_critical_section
is that
the current dynwind context (see Dynamic Wind) turns into a
critical section. Because of the locked mutex, no second thread can
enter it concurrently and because of the blocked asyncs, no system
async can reenter it from the current thread.
When the current thread reenters the critical section anyway, the kind of mutex determines what happens: When mutex is recursive, the reentry is allowed. When it is a normal mutex, an error is signalled.
Next: Fluids and Dynamic States, Previous: Blocking, Up: Scheduling [Contents][Index]