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 cyril@be.com.

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.

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 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: http://www.be.com/aboutbe/mailinglists.html.