Jeff V. Merkey wrote:
In 2-3 years we might actually see the hardware solution, maybee ....
I am skeptical Intel will move quickly on it. A software solution will
get out faster.
I'm not sure a hardware solution is even the right thing - consider a
shared memory database process with a private heap. You really want
locks on the shared memory, and you really don't on the heap.
You need a way to type the lock semantics by memory region, and a
working hardware solution can not perform as well as a careful software
solution. As was pointed out earlier, you can't use memory type
attributes to infer lock semantics, you must assume them in the decoder
or implement complex deadlock detection and recovery in silicon.
I would be willing to bet that library users know best. Most cleanly
written libraries already have wrapper functions that can be used to
plug in needed libc functions like malloc, even file I/O. Even if they
don't, you can rewrap all of the imported functions. Using this, you
can isolate threaded libraries from single threaded applications, and
make sure the performance critical libraries use non-threaded
operations. You can even afford to use a medium heavy hammer and switch
from non-threaded to threaded dependent libraries every time you call a
thread-using library function, because by assumption, the majority of
performance critical code is going to be running single threaded.
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]
