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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
