Re: [patch] SMP alternatives

[Zachary Amsden]

Bill Davidsen wrote:

> Linus Torvalds wrote:
>
> > In contrast, the simple silicon support scales wonderfully well. 
> > Suddenly libraries can be thread-safe _and_ efficient on UP too. You 
> > get to eat your cake and have it too.
>
>
> I believe that a hardware solution would also accomodate the case 
> where a program runs unthreaded for most of the processing, and only 
> starts threads to do the final stage "report generation" tasks, where 
> that makes sense. I don't believe that it helps in the case where init 
> uses threads and then reverts to a single thread for the balance of 
> the task. I can't think of anything which does that, so it's probably 
> a non-critical corner case, or something the thread library could 
> correct.


Startup routine of a scientific app calls a multithreaded "fetch work" 
routine, then crunches the data using a single thread.  This could even 
happen somewhere inside a library, so the application itself is unaware 
that threads were ever invoked.  This is not a far-fetched case.

You really need per-address object notions of "threadedness" when 
talking about shared memory, since you may need shared memory to be 
atomic, but operate on the heap in single threaded fashion.

Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/