Issue 1-37, August 21, 1996

Be Engineering Insights: The Kernel Scheduler and Real-Time Threads

By Cyril Meurillon

Not much has been disclosed about the internals of the kernel scheduler. It's time to explain in detail how it works, so that real-time application programmers know what they can expect from it and can make better use of it. In this article, I discuss the kernel scheduler as it has been implemented since Developer Release 7.

The scheduler distinguishes between two classes of threads: "time-sharing" and "real-time." The thread's priority level determines which category it falls into. The priority range 1-99 is used for time-sharing threads; 100-120 is used for real-time threads. Within each class, threads are further differentiated using their relative priorities.

A real-time thread is executed as soon as it's ready. If more than one real-time thread is ready at the same time, the thread with the higher priority is executed first. The thread is guaranteed to run without being preempted (except by a real-time thread with a higher priority) until it invokes a blocking system call (semaphore, ports, snooze, I/O, and so on).

A time-sharing thread is executed only if there are no real- time threads in the ready queue. When this condition is satisfied, a time-sharing thread is elected in a probabilistic manner based on its priority, using a logarithmic scale of base 2. For example, a thread with a priority 8 is four times more likely to be elected than a thread with a priority 6. A new time-sharing thread is reelected regularly, once every "scheduler quantum" (currently, every 3 milliseconds).

Because the BeBox is a multiprocessor machine, things are actually a bit more complex. But the rules described still apply: No time-sharing thread is allowed to stand in the way of a real-time thread. For example, if CPU 1 is executing real-time thread A, it's possible for a time-sharing thread B to run on CPU 2. (Note that on a single-processor system, B would have to wait until A blocks.) If real-time thread C wakes up, it would immediately interrupt B on CPU 2 and run there, without interfering with A.

If you look at the header file OS.h (in DR8), you will see some predefined priorities. With each real-time priority, there's an associated "maximum latency" (described in the comment next to each priority constant). This latency is the maximum time that a thread can afford to sit in the ready queue without being executed. Note that these maximum latencies are *not* enforced by the scheduler—these are guidelines, not guarantees. As a developer, you can use the latency guidelines to find the appropriate priority for your real-time thread.

In the real-time class:

B_REAL_TIME_PRIORITY (120)—latency 0.5-1 ms Used for the most demanding real-time tasks, such as audio. We currently use this one for the threads in the chain feeding the DAC.

B_URGENT_PRIORITY (110)—latency 5-10 ms Used for slightly less demanding tasks. We use it for MIDI.

B_REAL_TIME_DISPLAY_PRIORITY (100)—latency 10-30 ms We use this one for the app_server threads poller and mouser, in charge of reading the keyboard and displaying the cursor.

In the time-sharing class:

B_URGENT_DISPLAY_PRIORITY (20) We don't use this one yet. You shouldn't use it either.

B_DISPLAY_PRIORITY (15) This is the priority of window threads, where updates take place.

B_NORMAL_PRIORITY (10) This is the priority of all other system-created threads.

B_LOW_PRIORITY (5) This is for threads that run in the background, without disturbing any other threads.

When designing a real-time application, analyze its real- time constraints. If the maximum tolerable latency falls below 0.5 milliseconds, then the BeBox isn't (yet) the right platform for that application. However, for anything higher than that, you should pick the priority with the matching latency.

Real-time threads must limit themselves to operations that truly require real-time attention. A healthy respect for this rule is essential to the proper behavior of the system. Memory allocation, for example, should be done by a normal priority time-sharing thread. The real-time thread should only access buffers that have already been allocated (and locked in memory, if necessary).

Another factor to keep in mind when composing your real-time thread is whether a particular function call will "lock" the underlying system resource or component. Most of the components of the BeOS™ are reentrant, and so calls on that component can be used in a real-time application. But some components aren't reentrant; functions that access these components are automatically locked while they're being used. This can degrade performance. For example, the file system (in its current state) may lock the I/O system for long periods. This can be a problem for certain real- time applications as we cannot guarantee reasonable latency for disk I/O. We're quite aware of these limitations and are constantly working to eliminate them.

If you run into any problem while designing or programming your real-time application, or if you have a question, you can contact me at

Be Developer Talk: Chris Wilkinson, Michigan State University

By Chris Wilkinson

In addition to being a full-time student at Michigan State University, I'm a computer support assistant for the department of physics and astronomy. My areas of study, astrophysics and computer engineering, afford many opportunities to work on a wide variety of projects. Within the astronomy group alone you can find a number of application areas, ranging from control of telescopes to data acquisition.

The platforms I choose, both personally and departmentally, must contain a highly responsive operating system. They must be able to multitask effortlessly and be fully compatible with a wide range of hardware. The Be systems and BeOS serve these purposes well—although there's always room for expansion.

The BeBox's potpourri of technologies displays something I've been expecting for years: The convergence of multiplatform technology to achieve a heightened level of functionality. Very few machines come ready with a GeekPort™ and other such innovations integrated into the OS. I see great potential, and I hope to utilize these features to their full extent.

My short term plans include using a BeBox in a mass data acquisition and control system. This system includes simultaneous information input and control output according to a set of preprogrammed equations and instructions. Long-term plans include MIDI sequencing, among other things.

I think that Be is doing a great job of not getting caught in the typical "developer shunning" that other computer hardware and software firms have gotten into. Companies like Commodore, NeXT, and others made a great debut, but they weren't responsive to the tides of an ever-changing world.

CHRP, Bad News, Good News

By Jean-Louis Gassée

Not all the news was good at Macworld. One disturbing item was the announcement by Apple's senior management that their CHRP (Common Hardware Reference Platform) boxes would ship later than expected -- probably by the fourth quarter of 1997. This is bad news for the PowerPC family. But the extent of the delay might trigger a healthy reaction and end up creating a sense of urgency, finally, for a much needed standard hardware platform, for an equivalent to the PC/AT for the PowerPC.

The concept of a reference platform isn't new or difficult. We all saw the birth and the growth of a huge industry based on derivatives of IBM's PC/AT design. When IBM transmogrified its RS processor family into the PowerPC, it published a PowerPC Reference Platform design. We used PREP as the basis for the design of the BeBox, adding multiprocessing and richer I/O not explicitly envisioned by the platform designers, probably because of their corporate roots in the PC business. This was in 1994.

Where are we two years later? Not much further along. Motorola, Apple, and IBM got together and transformed PREP into CHRP. Basically, this was done in order to make room in the platform definition for Macintosh compatibility. This complicated things a little and there were other issues related to the commitment of silicon vendors to making building blocks for CHRP, but with a champion the size of Apple, CHRP had to be a success.

It's now transpiring that Apple's commitment to CHRP was perhaps less total than formerly trumpeted. Such tepid engagement might be connected to the success of Power Computing. In the eyes of some, Power Computing and others could take away large portions of the hardware business if CHRP became a true industry platform. CHRP could threaten Apple's current control of its licensing business.

Today, Apple's licenses are not licenses in the commonly accepted sense of the term. You don't get a license to the Mac OS in the same sense as getting a license to run Windows or UNIX on your PC clone. In the PC world, unless you're really stupid or crazy and as long as you stick to some basic hardware rules, you design a motherboard, you buy your BIOS from a specialist such as AMI, Phoenix, or Award, and Windows runs on your PC without any special interaction with the system software supplier, Microsoft. For an Apple licensee, it's different. For each motherboard design, Apple designs proprietary ASICs (roughly equivalent to a chipset in the Wintel world) and adapts the Mac ROMs (the rough equivalent of a BIOS) to the hardware. Then the Mac OS and applications can run, ignoring hardware particulars. In the Apple cloning world, the licensee gets a license to a motherboard design, permission to buy ASICs and ROMs, and a Mac OS distribution license. I might oversimplify a little here and there, but you get the picture: The Apple licensee needs much more than the Mac OS from Apple. Without access to ROMs and ASICs, you can't build a clone.

For those confronting the Byzantine world of Apple licensing, CHRP promised to be a welcome simplification. But not a total one. The CHRP spec still stipulated that Mac OS specific ROMs be purchased from Apple (or from a designated vendor). Today, Apple can modify its hardware almost at will. In theory, by controlling both the hardware and the software, it can move the platform forward, incorporate new technology more easily, and in the process, produce a better-integrated, smoother, more reliable product. Apple's control of the hardware and software layers might yield another byproduct when fine-tuning control of the company's licensing business. While I'm not intimately familiar with the terms of its licenses, I can imagine a situation where a licensee does not get a license to a new design and the required ASIC and ROM building blocks, or not right away, or not automatically.

Perhaps CHRP was perceived as a threat to Apple's ability to control licensees, and Power Computing's striking success might have given weight to the fear. As a result, CHRP- compliant hardware and software got delayed, thus threatening the advent of a truly standard PowerPC platform.

Hopefully, Apple's new management realizes the importance of creating such a standard. But we know that management fiats rarely accelerate existing projects. The way out might be to just ditch CHRP. It was getting unconvincing or unconvinced support from the other players anyway. Take any reasonable current or imminent hardware design, call it nCHRP or whatever, and make it easy or easier to buy the ASICs and ROMs -- as easy as it is to buy a chipset and a BIOS in the Wintel world. Of course, it's easier said than done, and the transition to a true platform might feel threatening. But no one's business or credibility will be helped by a failure to deliver a standard PowerPC platform in 1997.

BeDevTalk Summary

BeDevTalk is an unmonitored discussion group in which technical information is shared by Be developers and interested parties. In this column, we summarize some of the active threads, listed by their subject lines as they appear, verbatim, in the mail.

To subscribe to BeDevTalk, visit the mailing list page on our web site:


Subject: root directories AKA: Sneering at UNIX...

The "what's in /?" thread veered into a UNIX (pro or con) shouting match after someone posed the rhetorical question "Is it too much to ask for a multi-media enhanced UNIX in 1996?" A few days later, the thread co-opted the OpenBoot discussion.


Subject: Unicode

Here were gathered opinions on whether Unicode is the best way to handle non-Western characters, how one should sort CJK (and "extended" Western characters—umlauts and such), what happens when you pass a CJK character to a function such as toupper(), and so on.

Subject: Re: Multi-headed BeOS and down with the Network Computer

A previous request for FireWire to support a multiheaded system was rebutted by the opinion that fiber would be better. It seems that the FireWire wire has length limitations unless you resort to "repeaters."


Subject: Pivot monitor support?

At what level of the OS/driver world would you insert the intelligence to support a 90 degree pivotable monitor? Should the BeOS and hardware be "open" so a third-party could provide an implementation directly? Alternatively, should Be provide indirect hooks? Following the latter, it was suggested that the OS should provide hooks for arbitrary display sizes and orientations. It was also pointed out that intelligent switching between portrait and landscape layout requires a driver (or some part of software) that can move windows so they stay on the screen.

Subject: Spaces in Filenames

It was proposed that spaces in filenames be converted to underbars when the name is displayed in a shell. This would (it was opined) make the life of the CLI user a wee bit nicer. The proposal was fairly unanimously rejected; tempers flared.

Subject: Case Sensitive File Names

Or "When is an 'a' not an 'A'?" Should filenames be case sensitive? Many opinions here. Well, actually, only three opinions: "Yea," "nay," and "sometimes." But lots of mail. LOTS of mail. (Uhm... is "lots" the same as... nevermind.)

Subject: An Alternative View

AKA: Persistent Object Store as Filesystem

This thread was sprouted from the case sensitivity debacle. To squeeze a number of its ideas together the argument goes something like this: Files should be replaced by database- managed objects that would be accessed through queries and that would be visible at the programming level AND the user level. The boundary between a document and the application(s) that can open it would be intentionally blurred.

There was some grumbling (How are existing foreign file systems supported? Will programmers *really* be able to throw away their file system crutches and walk? If the result is hierarchical, how is it different from the file system?), but, in general, there was little objection to the object/document metaphor.

Subject: Introduction

After a shaky start (Tangerine Dream? Let's all go to Izzy's house, turn on the black lights, and imagine we're at the edge of the universe.) this thread became a clearing house for "audio jukebox" ideas. Such a device could use IR or the GeekPort to search through and play tracks from a stack of CDs (or, in the future, DVDs).

Subject: Screen saver formats

Windows recognizes .SCR; the Mac knows After Dark. How about a Be screen saver format and API? It was pointed out that you can run screen saver modules in Saver. See for the engine; also, for some modules.

Subject: StartUp Directory

A "StartUp" directory, which would contain programs that would be launched automatically when you boot, was proposed. A counterproposal suggested that it would be better to use the database to tag auto launch apps.

Subject: Re: BeBox as music-machine

Could a BeBox be used as (for example) a ten-input real-time audio mixer? It was pointed out that you would at least need some extra equipment to (multiplex?) the inputs, since the BeBox only has two line-in signals. We also heard from Steve Ellison of Level Control Systems. He described the massive audio control system (with outboard equipment) that they're building.

Creative Commons License
Legal Notice
This work is licensed under a Creative Commons Attribution-Non commercial-No Derivative Works 3.0 License.