[cpp-threads] Re: Berlin meeting

Lawrence.Crowl at Sun.com Lawrence.Crowl at Sun.com
Wed Apr 19 18:09:25 BST 2006


>Threads API (or syntax):
>
>We spent a fair amount of time discussing this, in large part from first
>principles.  The discussion was still in progress when I left, but seemed to
>be starting to converge, at least slightly.  Lawrence Crowl ran some of this
>discussion, including the final piece, so I'm not sure about the final
>status.  He may be able to comment and/or submit a summary as a committee
>paper.

Here are the minutes from that meeting.

  Lawrence Crowl             650-786-6146   Sun Microsystems, Inc.
                   Lawrence.Crowl at Sun.com   16 Network Circle, UMPK16-303
           http://www.Crowl.org/Lawrence/   Menlo Park, California, 94025
-------------- next part --------------
<html><head><title>Thread Subcommittee Minutes from Berlin</title></head>

<body>

<h1>Thread Subcommittee Minutes from Berlin</h1>

<p>N2012=06-0082, 2006-04-18, Lawrence Crowl

<p>In wide-ranging discussions,
the thread subcommittee asked and answered
a number of questions about how to introduce threads into C++.

<h2>Structure</h2>

<table border>
<tr><td>Are threads hierarchical?</td>
<td>No, use OpenMP.</td></tr>
<tr><td>Are threads flat peer-to-peer?</td>
<td>Not completely, some management tasks become difficult.</td></tr>
<tr><td>Is there a master thread?</td>
<td>Yes, it executes main.</td></tr>
<tr><td>Are threads compatible with the system?</td>
<td>Yes.  Anything else will be perceived as less than helpful.</td></tr>
</table>

<h2>Creation and Termination</h2>

<table border>
<tr><td>Shall threads be explicit?</td>
<td>Yes.</td></tr>
<tr><td>Are threads coarse-grained?</td>
<td>Yes.</td></tr>
<tr><td>Is thread creation dynamic?</td>
<td>Yes.</td></tr>
<tr><td>If so, is it program controlled?</td>
<td>Yes.</td></tr>
<tr><td>Is work explicitly asigned to threads?</td>
<td>Yes.</td></tr>
<tr><td>Can one call exit only from the master thread?</td>
<td>Yes, calling exit from a non-master thread induces an abort.</td></tr>
<tr><td>What happens when exit is called while threads are detached?</td>
<td>The result is implementation-defined.</td></tr>
<tr><td>Is there a join operation?</td>
<td>Yes.</td></tr>
<tr><td>Are exceptions propogated through the join?</td>
<td>Yes, otherwise they become unmanagable.
This propogation requires syntax or library ABI magic.
</td></tr>
<tr><td>Should there be a join any or join all?</td>
<td>Not in the base layer, leave it to higher layers.</td></tr>
<tr><td>How are thread objects allocated?</td>
<td>Dynamically, on the heap.
Thread objects on the stack are problematic
if an exception deletes the object,
better perhaps is dynamic allocation of the exception object.</td></tr>
<tr><td>May threads be detached?</td>
<td>Yes, it means there will be no join operation
and the thread object may delete itself
on return from the thread function.</td></tr>
</table>

<h2>Dynamic Libraries</h2>

<table border>
<tr><td>Does the master construct all globals variables?</td>
<td>Maybe.  The issue is a dlopen from a non-master thread
and the subsequent initialization of globals.</td></tr>
<tr><td>Shall we require dlopen only from a master thread?</td>
<td>No, this inhibits MT-hot libraries.</td></tr>
<tr><td>Shall the implementation serialize all dlopens?</td>
<td>Leave this implementation-defined.</td></tr>
<tr><td>Shall we prohibit calling dlopen while holding a lock?</td>
<td>No, this approach violates encapsulation in the library.</td></tr>
<tr><td>Are recursive dlopens defined on different libries?</td>
<td>Yes.</td></tr>
<tr><td>Must non-recursive dlopens be serialized by user code?</td>
<td>Maybe.</td></tr>
</table>

<h2>Communication and Synchronization</h2>

<table border>
<tr><td>Is communication via message?</td>
<td>No, use MPI.</td></tr>
<tr><td>Is communication via shared memory?</td>
<td>Yes.</td></tr>
<tr><td>Is synchronization via locks?</td>
<td>Yes.</td></tr>
<tr><td>If so, events or condition variables?</td>
<td>Condition variables.  They are much easier to use.</td></tr>
<tr><td>Can threads synchronize between processes?</td>
<td>Make possible, but not defined.</td></tr>
<tr><td>Can threads synchronize with system threads?</td>
<td>Yes.</td></tr>
<tr><td>Can threads obtain handles on system threads?</td>
<td>Yes, for scheduling.</td></tr>
<tr><td>Are static-duration variables synchronizable?</td>
<td>Yes.</td></tr>
<tr><td>Are static-duration variables explicitly synchronized,
e.g. __synchronized keyword?</td>
<td>Maybe.  The issue is that it might be better
if they were all implicitly synchronized.</td></tr>
<tr><td>Are locks in a library?</td>
<td>Yes, there is a substantial variety.</td></tr>
</table>

<h2>Scheduling</h2>

<table border>
<tr><td>Is progress guaranteed?</td>
<td>No.</td></tr>
<tr><td>Are scheudling hints available?</td>
<td>Maybe.  Revisit this issue.</td></tr>
<tr><td>Can one call terminate/abort anywhere?</td>
<td>Yes, and terminate immediately.</td></tr>
<tr><td>Can a thread cancel itself?</td>
<td>Maybe.</td></tr>
<tr><td>Can a thread cancel other threads synchronously?</td>
<td>Maybe.</td></tr>
<tr><td>Can a thread cancel other threads asynchronously?</td>
<td>No, this does terrible damage to code generation.</td></tr>
<tr><td>Can a thread suspend itself?</td>
<td>No.</td></tr>
<tr><td>Can a thread suspend others?</td>
<td>No.</td></tr>
<tr><td>Can a thread yield itself?</td>
<td>Maybe.</td></tr>
<tr><td>Can a thread yield other threads?</td>
<td>No.</td></tr>
</table>

<h2>Thread-Local Storage</h2>

<table border>
<tr><td>Is there a __thread keyword?</td>
<td>Yes.</td></tr>
<tr><td>May function-local thread-local variables
be dynamically initialized?</td>
<td>Yes.</td></tr>
<tr><td>May other thread-local variables be dynamically initialized?</td>
<td>Implementation defined.</td></tr>
</table>

</body></html>



More information about the cpp-threads mailing list