Linked by Thom Holwerda on Sun 10th Jul 2011 18:50 UTC, submitted by moondevil
Microsoft "The Microsoft and ETH Zurich research teams have published the source code of Barrelfish, a multikernel operating system for the multicore heterogeneous hardware of the future. Today's operating systems have been adapted to work on multiprocessor and multicore hardware, but they were not initially designed with multicore in mind, and they are not ready for heterogeneous hardware with hundreds of cores that is to come in the following ten years. The main problem is the concept of shared-memory and the contention arising from accessing the same data protected by locks. This is the problem that Barrelfish wants to address."
Thread beginning with comment 480281
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Worthwhile?
by AndrewZ on Mon 11th Jul 2011 16:43 UTC in reply to "RE[2]: Worthwhile?"
AndrewZ
Member since:
2005-11-15

That feature would be trivially doable on just about any OS, the way it works in BeOS/Haiku isn't by actually physically disabling the CPU, it simply tells the scheduler to not schedule anything other than the idle thread on it (until one marks that CPU as enabled again in Pulse or ProcessController) ; the CPU is still very much active.


Thanks for correcting my misconception, interesting to know. If you were going to trivially code that in Windows, what would the code look like? Just curious.

Edited 2011-07-11 16:44 UTC

Reply Parent Score: 2

RE[4]: Worthwhile?
by anevilyak on Mon 11th Jul 2011 17:27 in reply to "RE[3]: Worthwhile?"
anevilyak Member since:
2005-09-14


Thanks for correcting my misconception, interesting to know. If you were going to trivially code that in Windows, what would the code look like? Just curious.


I meant in the context of the kernel it'd be trivial. The way it works on Haiku is that there's a per-CPU data structure in the kernel that describes the CPU and various scheduling-related information related to it. one of said pieces of information is a simple boolean indicating that the CPU is enabled or not. To go with that, there's a syscall that allows one to set said boolean (which is what Pulse or anyone else wanting to do that calls). When the thread scheduler on a given CPU kicks in, it looks at that first, and if that boolean is set, it simply goes straight to the idle thread pool to pick the next thread to schedule. Otherwise it does the usual scheduling run (which in Be/Haiku's case effectively amounts to: 1) round-robin select any real time threads that are ready. 2) If none, round robin through the non-realtime threads, except pull a random number when selecting one which decides whether or not to skip the thread on this run. This is done to allow lower priority threads a chance to occasionally run in the event that a higher pri one goes into a loop due to a bug or whatnot, since it allows some modicum of control to kill the offending process, as it means the GUI will occasionally get some cycles.)

On Windows one can do something loosely similar in Task Manager if you right click a process and pick "Set Affinity". This allows you to restrict the subset of CPUs a given process is allowed to run on. Not entirely the same thing, but what you're doing with Pulse is effectively the same as doing that for every single process in the system.

Reply Parent Score: 2