Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment Re:performance (Score 1) 141

According to the page that you have linked, "Below is a partial list of categories in which people have published after joining Google. There is also a list organized by year, and an atom feed is also available. "

These are not research projects specifically funded by Google, but rather published by people working at Google.

Comment Re:Kernel locking (Score 2) 135

Put simply, when you have many independent bits of code competing for finite shared resources/time within the kernel (this is different than code just running in user space), you have to put locks on them so that only 1 thread can access them at a time. Once a lock is released then the another thread gets a turn. With a big lock, only one lock exists for every resource. Although a thread may only need access to a single resource, all of the resources get locked.

The alternative is to implement more fine-grained locks on each resource or set of resources. This allows two threads that are using different kernel resources to potentially execute in parallel. The danger is it's more complex and requires careful coding to avoid deadlock or race conditions. That help?

http://blog.internetnews.com/skerner/2010/11/linux-2637-kills-the-big-kerne.html

Slashdot Top Deals

You have a message from the operator.

Working...