Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:performance (Score 1) 141

by AntiGenX (#37039994) Attached to: Microsoft Demonstrates Practical Homomorphic Computing

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

by AntiGenX (#34770634) Attached to: Linux 2.6.37 Released

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

Brain off-line, please wait.

Working...