<p>The functionality described in this section should only be used by experts, and even by those only with caution (especially the parts that relate to the memory model).</p>
<p>Not only is it possible to crash or hang the GAP kernel, it can happen in ways that are very difficult to reproduce, leading to software defects that are discovered only long after deployment of a package and then become difficult to correct.</p>
<p>The performance benefit of using these primitives is generally minimal; while concurrency can induce some overhead, the benefit from micromanaging concurrency in an interpreted language such as GAP is likely to be small.</p>
<p>These low-level primitives exist primarily for the benefit of kernel programmers; it allows them to prototype new kernel functionality in GAP before implementing it in C.</p>
<h4>11.1 <span class="Heading">Explicit lock and unlock primitives</span></h4>
<p>The <code class="func">LOCK</code> (<a href="chap11.html#X828E21CD78EFE07A"><span class="RefLink">11.1-1</span></a>) operation combined with <code class="func">UNLOCK</code> (<a href="chap11.html#X7EBEFBC6875F149A"><span class="RefLink">11.1-3</span></a>) is a low-level interface for the functionality of the statement.</p>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ LOCK</code>( [<var class="Arg">arg_1</var>, <var class="Arg">...</var>, <var class="Arg">arg_n</var>] )</td><td class="tdright">( function )</td></tr></table></div>
<p><code class="func">LOCK</code> takes zero or more pairs of parameters, where each is either an object or a boolean value. If an argument is an object, the region containing it will be locked. If an argument is the boolean value <code class="keyw">false</code>, all subsequent locks will be read locks; if it is the boolean value <code class="keyw">true</code>, all subsequent locks will be write locks. If the first argument is not a boolean value, all locks until the first boolean value will be write locks.</p>
<p>Locks are managed internally as a stack of locked regions; <code class="func">LOCK</code> returns an integer indicating a pointer to the top of the stack; this integer is used later by the <code class="func">UNLOCK</code> (<a href="chap11.html#X7EBEFBC6875F149A"><span class="RefLink">11.1-3</span></a>) operation to unlock locks on the stack up to that position. If <code class="func">LOCK</code> should fail for some reason, it will return <code class="keyw">fail</code>.</p>
<p>Calling <code class="func">LOCK</code> with no parameters returns the current lock stack pointer.</p>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ TRYLOCK</code>( [<var class="Arg">arg_1</var>, <var class="Arg">...</var>, <var class="Arg">arg_n</var>] )</td><td class="tdright">( function )</td></tr></table></div>
<p><code class="func">TRYLOCK</code> works similarly to <code class="func">LOCK</code> (<a href="chap11.html#X828E21CD78EFE07A"><span class="RefLink">11.1-1</span></a>). If it cannot acquire all region locks, it returns <code class="keyw">fail</code> and does not lock any regions. Otherwise, its semantics are identical to <code class="func">LOCK</code> (<a href="chap11.html#X828E21CD78EFE07A"><span class="RefLink">11.1-1</span></a>).</p>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ UNLOCK</code>( <var class="Arg">stackpos</var> )</td><td class="tdright">( function )</td></tr></table></div>
<p><code class="func">UNLOCK</code> unlocks all regions on the stack at <var class="Arg">stackpos</var> or higher and sets the stack pointer to <var class="Arg">stackpos</var>.</p>
<p>HPC-GAP supports <em>hash locks</em>; internally, the kernel maintains a fixed size array of locks; objects are mapped to a lock via hash function. The hash function is based on the object reference, not its contents (except for short integers and finite field elements).</p>
<p>Hash locks should only be used for very short operations, since there is a chance that two concurrently locked objects map to the same hash value, leading to unnecessary contention.</p>
<p>Hash locks are unrelated to the locks used by the <code class="code">atomic</code> statements and the <code class="func">LOCK</code> (<a href="chap11.html#X828E21CD78EFE07A"><span class="RefLink">11.1-1</span></a>) and <code class="func">UNLOCK</code> (<a href="chap11.html#X7EBEFBC6875F149A"><span class="RefLink">11.1-3</span></a>) primitives.</p>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ HASH_LOCK</code>( <var class="Arg">obj</var> )</td><td class="tdright">( function )</td></tr></table></div>
<p><code class="func">HASH_LOCK</code> obtains the read-write lock for the hash value associated with <code class="code">obj</code>.</p>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ HASH_UNLOCK</code>( <var class="Arg">obj</var> )</td><td class="tdright">( function )</td></tr></table></div>
<p><code class="func">HASH_UNLOCK</code> releases the read-write lock for the hash value associated with <code class="code">obj</code>.</p>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ HASH_LOCK_SHARED</code>( <var class="Arg">obj</var> )</td><td class="tdright">( function )</td></tr></table></div>
<p><code class="func">HASH_LOCK_SHARED</code> obtains the read-only lock for the hash value associated with <code class="code">obj</code>.</p>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ HASH_UNLOCK_SHARED</code>( <var class="Arg">obj</var> )</td><td class="tdright">( function )</td></tr></table></div>
<p><code class="func">HASH_UNLOCK_SHARED</code> releases the read-only lock for the hash value associated with <code class="code">obj</code>.</p>
<h4>11.3 <span class="Heading">Migration to the public region</span></h4>
<p>HPC-GAP allows migration of arbitrary objects to the public region. This functionality is potentially dangerous; for example, if two threads try resize a plain list simultaneously, this can result in memory corruption.</p>
<p>Accordingly, such data should never be accessed except through operations that protect accesses through locks, memory barriers, or other mechanisms.</p>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ MAKE_PUBLIC</code>( <var class="Arg">obj</var> )</td><td class="tdright">( function )</td></tr></table></div>
<p><code class="func">MAKE_PUBLIC</code> makes <var class="Arg">obj</var> and all its subobjects members of the public region.</p>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ MAKE_PUBLIC_NORECURSE</code>( <var class="Arg">obj</var> )</td><td class="tdright">( function )</td></tr></table></div>
<p><code class="func">MAKE_PUBLIC_NORECURSE</code> makes <var class="Arg">obj</var>, but not any of its subobjects members of the public region.</p>
<p>The memory models of some processors do no guarantee that read and writes reflect accesses to main memory in the same order in which the processor performed them; for example, code may write variable <code class="code">v1</code> first, and <code class="code">v2</code> second; but the cache line containing <code class="code">v2</code> is flushed to main memory first so that other processors see the change to <code class="code">v2</code> before the change to <code class="code">v1</code>.</p>
<p>Memory barriers can be used to prevent such counter-intuitive reordering of memory accesses.</p>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ ORDERED_WRITE</code>( <var class="Arg">expr</var> )</td><td class="tdright">( function )</td></tr></table></div>
<p>The <code class="func">ORDERED_WRITE</code> function guarantees that all writes that occur prior to its execution or during the evaluation of <var class="Arg">expr</var> become visible to other processors before any of the code executed after.</p>
<p>Here, the write barrier ensure that the assignment to <code class="code">y</code> that occurs during the call of <code class="code">f()</code> becomes visible to other processors before or at the same time as the assignment to <code class="code">x</code>.</p>
<p>This can also be done differently, with the same semantics:</p>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ ORDERED_READ</code>( <var class="Arg">expr</var> )</td><td class="tdright">( function )</td></tr></table></div>
<p>Conversely, the <code class="func">ORDERED_READ</code> function ensures that reads that occur before its call or during the evaluation of <var class="Arg">expr</var> are not reordered with respects to memory reads occurring after it.</p>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ SWITCH_OBJ</code>( <var class="Arg">obj1</var>, <var class="Arg">obj2</var> )</td><td class="tdright">( function )</td></tr></table></div>
<p><code class="func">SWITCH_OBJ</code> exchanges its two arguments. All variables currently referencing <var class="Arg">obj1</var> will reference <var class="Arg">obj2</var> instead after the operation completes, and vice versa. Both objects stay within their previous regions.</p>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ FORCE_SWITCH_OBJ</code>( <var class="Arg">obj1</var>, <var class="Arg">obj2</var> )</td><td class="tdright">( function )</td></tr></table></div>
<p><code class="func">FORCE_SWITCH_OBJ</code> works like <code class="func">SWITCH_OBJ</code> (<a href="chap11.html#X84644A1284D0AB35"><span class="RefLink">11.5-1</span></a>), except that it can also exchange objects in the public region:</p>
<p>This function should be used with extreme caution and only with public objects for which only the current thread has a reference. Otherwise, undefined behavior and crashes can result from other threads accessing the public object concurrently.</p>
Die Informationen auf dieser Webseite wurden
nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit,
noch Qualität der bereit gestellten Informationen zugesichert.
Bemerkung:
Die farbliche Syntaxdarstellung ist noch experimentell.