Subj : Re: Thoughts about threads in C++
To   : comp.programming.threads
From : Maciej Sobczak
Date : Fri Apr 29 2005 03:00 pm

Marcin 'Qrczak' Kowalczyk wrote:

>>a. creating a new physical thread and releasing it afterwards
>>b. reusing a thread that was created previously
>>c. run everything explicitly in separate pipelines of the multicore
>>CPU, which actually does not require any OS-level threading at all
>>d. (whatever else)
>>
>>By explicitly creating threads and messing with their IDs (or handles)
>>I bind myself to a. or b.,
> 
> No, you don't. The implementation can reuse threads, or implement
> them without OS-level threads. Your proposal doesn't make it easier.

My gut feeling is that by acknowledging the existence of concurrency at 
the level of language control statements, you give the *compiler* the 
insight into what will be executed in paraller. If the concurrent blocks 
of statements are relatively simple, the compiler might opt to skip the 
OS-level threading and prefer to directly push the instructions into 
separate pipelines of the multicore CPU (if that is possible).
By following the traditional approach where the concurrent statements 
are hiddent behind a pointer to function, you basically prevent the 
compiler from having this depth of insight and any further optimization 
options are therefore limited. (Of course, you can still reuse old 
threads instead of creating new ones each time it is requested.)

The difference is conceptually similar to that between std::sort (in 
C++) and qsort (in C). The former is way easier to optimize by code 
inlining just because the comparison operation is not isolated behind 
the pointer to function.

This is just my gut feeling, though. I do not know how smart the actual 
library-based thread implementations are.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

.