Light-weight threads

[Stanley Steel]

On 2/24/10 7:57 AM, Norbert Nemec wrote:
> ds wrote:
>> == Quote from Norbert Nemec (Norbert at Nemec-online.de)'s article
>>> Hi there,
>>> I just found that recent change in the language to make all global
>>> variables thread-local by default. This makes me think of a major
>>> performance problem: every thread creation will have to copy all the
>>> thread-local variables. This makes it impossible to efficiently spawn
>>> many light-weight threads even if they do not make use of the global
>>> variables at all.
>>> I guess I am not the first one to spot this problem? I believe that
>>> thread creation should come with as little overhead as possible. Maybe a
>>> concept of light-weight threads based on side-effect free code could
>>> complement the regular threads?
>>> Just a quick idea to throw into discussion...
>>> Greetings,
>>> Norbert
>>
>> What's wrong with using thread/task pools for these situations?
>
> That's always an option, of course. It just adds one layer of complexity
> to the code.
>
> If spawning a thread were as cheap as putting a task in a queue you
> could simply spawn one thread per task and leave it to the scheduler to
> handle it all. Assuming, of course, that the scheduler is clever enough
> to handle it efficiently.
The problem is they are divergent.  If I spawn a thread to reorder an 
array for the UI, then of course I use that thread again for the same 
task, its array hasn't been updated by all the new elements that the 
original was keeping track of.  Right?  I guess you could make it 
shared, but then how is it better than using a traditional language?