[cpp-threads] Proposing a layered Thread API

[Kevlin Henney]

Ion Gaztañaga <igaztanaga at gmail.com> writes
>Kevlin Henney wrote:
>> Ion Gaztañaga <igaztanaga at gmail.com> writes
>>>
>>> Thoughts? Do you see a 3 level approach correct? It's too 
>>>complicated?  Too hard to implement?
>>  My gut instinct is that it will be perceived as overly complicated. 
>>Any  issues concerning implementation are almost irrelevant in 
>>comparison to  the question of usability. Two levels seems simple and 
>>effective enough,  as well as easy to explain, but the three levels 
>>presented are  conceptually too close and offer more choice than most 
>>would consider  desirable, useful or practical. In library design, 
>>more choice does not  necessarily equate with better.
>
>So I suppose you prefer levels 0 and 2, with a direct OS control plus a 
>reference counted future?

Assuming a level 0 that looked like the one Howard sketched out in the 
form of "thread" (in essence, "joiner" constrained), which embodies a 
limited future concept: one that can be moved but not copied and shared.

>I think that can have a big performance impact. Like parallelization 
>software (OpenMP, Intel Thread Building Blocks...), the user will 
>prefer a main thread parallelizing loops and asynchronous IO/threads so 
>that the main thread launches and joins all the operations. In that 
>case, I think that reference-count + copy is quite expensive.

If I understand you correctly, I think what you are outlining is already 
possible without shareable futures: what is missing is an appropriate 
grouping concept to allow such multi-joins.

I also don't see why a reference count plus a copy will be expensive. 
There is no significant space overhead to a reference count and no 
additional allocations required and, unless someone is pathologically 
making copies all over the place, there is little cost associated with 
copying. Perhaps you could clarify where the reference count plus copy 
overhead is.

>I don't know what Java Future interface does and if concurrent joins 
>from different threads at the same time are used, but I would like to 
>see an example to convince me that reference counted + concurrent joins 
>are really meeded.

Shareability is a commonly used property of futures. In the case of 
Java, there is obviously no reference count or copy mechanism.

If you need to pick up a result or need to synchronise with a thread's 
completion, "thread" is sufficient [*]. If you want to share this 
ability, then "future" would appear to be the right way to go.

Adding more features to the API just seems to add more concepts and 
complexity but it does not seem to add value. There is already enough 
experience within C++ and outside it that shows the basic value of a 
future concept. Hopefully I haven't missed an assumption, but please let 
me know if I have.

Kevlin

[*] Hmm, given the frequent need to use quotes for clarification, I am 
beginning to think that renaming "joiner" to "thread" was perhaps not as 
practical an idea as it first appeared :-} The object type in question 
is categorically not itself a thread and makes talking about threads 
slightly more awkward. I am not wed to "joiner", but in discussion the 
name "thread" actually seems less clear.
-- 
____________________________________________________________

   Kevlin Henney                   phone:  +44 117 942 2990
   mailto:kevlin at curbralan.com     mobile: +44 7801 073 508
   http://www.curbralan.com        fax:    +44 870 052 2289
   Curbralan: Consultancy + Training + Development + Review
____________________________________________________________