Ever interested in broadening my understanding of the world around me, I recently checked into the web sites of IBM, Sun, and NCI (the subsidiary of Oracle which incorporated Navio and is dedicated to producing network computers under the benevolent and watchful eye of Larry Ellison) to have a look at their NC offerings.

An NC, as far as I can tell, is a computer designed to run a web browser, has a convincing Java implementation, can't be screwed up by the user, has no local storage, can be booted from a server and configured remotely by an all-knowing authority. Also, it should be cheap. And most people seem to think it would be a good idea if it did all this without any Microsoft software whatsoever, although that's mostly coming from manufacturers, not end users.

Some quick perusals of the web sites quickly yield a fairly traditional profile: a slim box with a non-Intel processor, no IDE, serial, parallel, or any peripheral connectors to speak of, an SVGA connector, keyboard and a mouse. Usually they're packaged in a handsome black design, and carry price tags around $700 (to start, monitor not included).

Of course, the value of these things is lower cost of ownership, and we're not just talking about purchase price, because we all know the real price comes from operational costs after the machine has been bought.

What I don't quite understand is the reason for a whole new computer to run this new software. I actually just bought a machine down the street (for which purpose I'll not disclose) which on closer inspection was a lot like the machine I just described. I saw it advertised in a not very elegant ad in Microtimes:

166 MHz Pentium MMX
32 MB RAM
1.44 MB Floppy
S3 Accelerated Graphics (2MB RAM)
Case/Power Supply
Keyboard/Mouse

Price: $495.

It needs a monitor, but as it stands, it seemed like it would make a pretty powerful NC. But what it needs is software.

You see, if I forget about all that fancy NC hardware which people want to sell me, and focus on the software which might make the machine I mention above an easily and remotely configurable NC, I realize that the NC argument is and should be a software argument. The computer above, relieved from the worries of a previous life imposed by Windows '95, could remotely (DHCP/BootP) retrieve a nice, simple and fast OS designed for web based computing and be as cost-effective an NC as anything in a fancy box from a NC hardware manufacturer.

I guess it's just more fun to build your own hardware. Or maybe it's easier to disguise your real intent. Never underestimate the possible manifestations of that less talked about Freudian condition, "Bill Gates Envy."

To paraphrase an old saying, if you're a hardware company, everything looks like a hardware problem, even a software problem.

So, is a spinlock a good thing? Last week when I went over what might be a typical spinlock implementation, astute readers immediately pointed out the flaws in the implementation, which is a good thing. I'll get back to that.

Why would you bother trying to implement such things in the first place? Well, many times you might think system resources are limited and must be preserved at all cost, and that system overhead must be minimized wherever possible. This sometimes leads developers to try and optimize areas they believe to be piggish before looking at their own algorithms.

Why did I use spinlocks as an example? Because, there is often times an assumption by speed demons that any function that calls into the kernel must be slow, and therefore is subject to optimization. Spinlocks are often thought of as a mechanism that provides a faster fine grain locking mechanism than semaphores.

The BeOS is a awesome system to work with, and very efficient at many things. If you have experience with other operating systems that do multi-threading, you might think it would be piggish doing certain things.

Multithreading from the bottom to the top is truly our motto. This has been the case from the first Hobbit-based BeBox to the multi-Pentium systems we run on today. If there is one thing we do right and efficiently, it's dealing with multiple threads running on multiple CPUs. That includes scheduling, locking critical areas, managing interrupts, etc. I think the BeOS handles these features much better than many other operating systems I have used in recent history.

One feature of programming in a new environment is that there are not shelf loads of books of the "Undocumented" variety available yet. Although this form of book tends to be a bit tedious at times, they do offer one very useful insight. You can typically find out the things that the standard documentation didn't tell you. That is, patterns of usage, and boundary cases.

The BeOS documentation is wonderful in explaining how things work, and although we try to tell you every minute detail of using every function, we may not meet your needs in all instances. But, being the industrious, inquisitive undaunted programmer that you are, you've taken to reading through headers to supplement your knowledge as much as you can. Of course this process is not ideal and in certain areas you must deduce certain behavior, and sometimes those deductions can be wrong.

If you are interested in how to control a thread's access to critical data, or interested in controlling the order of processing that occurs in your application, you absolutely must read the documentation on semaphores, which can be found on your BeOS disk at:

file:///boot/beos/documentation/Be%20Book/kernel/sems.html

If you are new to multithreaded programming, but you love to do experiments with programming, you might do some reading on semaphores and come to the conclusion that you can do better. Last week's sample code is a typical example of how you might try to implement it on your own.

For instance, if you're coming from the UNIX/Solaris/Linux world, you might have read "UNIX Systems for Modern Architectures" by Curt Schimel and come across section 9.2 Spin-Locks. It seems like a good idea. A fine grained locking mechanism that doesn't do too much other than waste CPU cycles. So you start to implement...

First you see that you need a test_and_set() function. It needs to flush caches and test and set a value in an atomic way. Using swap_atomic is what is advocated, so you go traipsing through the Be documentation looking for such a function. Not finding it directly, you start looking through headers and come across SupportDefs.h which has nifty things like atomic_add, atomic_and, write_32_swap, and the like. You take a gamble and come up with:

long test_and_set(volatile long *addr)
{
    long old_value;
    old_value = write_32_swap (addr, 1);
    if (old_value == 0)
        return 0;
    return 1;
}

It's close, but not quite. First, the write_32_swap() doesn't return a int, but your compiler doesn't complain, so you think you're safe.

The code that will call this function wants to do one thing. If the value is 0, then set it to one atomically and return the fact that it was 0. If it is 1, then return the fact that is a one.

The proper way of doing this is to use the atomic_or function. The atomic_xxx functions return the value that was in the variable before it was changed. Thus, if it were already a 0, it would return that and the current value would now be a 1. If it were a 1 to begin with, it will return that, and it will remain a 1. Ahhh... perfect.

long test_and_set(volatile long *addr)
{
    return atomic_or(addr, 1) ? 1 : 0;
}

But you're not done. There may be multiple CPUs in the system. Do you need to flush caches explicitly so that the other CPUs will know that the memory address changed? Do you even know how to get to the caches? Or did that happen for you automatically when you used the atomic_or function? And how costly is that spinning anyway?

In the BeOS, and any other system for that matter, the atomic_xxx operations are supposed to be guaranteed by the OS vendor to do all those things. Flush caches if necessary, and utilize the proper CPU instructions to achieve the desired action while disallowing other actions from interfering.

The critical method of the ASpinLock class is the Lock() method itself. It does the test_and_set forever until it actually gets a hold of the "lock." Is this a good thing to do in user space? Not necessarily. Since the BeOS is preemptive, your process is subject to rescheduling. That means the kernel gets involved and does some context switching, which is what you might have been trying to avoid in the first place.

int ASpinLock::Lock()
{
  while (test_and_set(&fLockStatus) == 1)
    ;
  return 0;
}

What does that leave you with? Back to the Benaphore? Yes, of course. A Benaphore as explained in a previous newsletter article is a very fast, efficient locking mechanism. It has been written, debugged, and presented for your usage in the documentation. It does a quick test on a atomic variable, and then uses a semaphore if necessary. Yes, you make a trip to the kernel, but you were probably headed there anyway.

Spinlocks are still a very useful locking mechanism, when implemented correctly and in the right places. If you are writing kernel device drivers, spinlocks are your best friend for protecting critical sections of code. You will find drivers/KernelExport.h provides you with the appropriate function calls for your device driver to handle spinlocks. The following header file comment gives you a good idea of proper spinlock usage:

/*---
  spinlocks. Note that acquire/release should be called with
  interrupts disabled.
---*/

That right there is your clue the spinlocks aren't quite as easy to implement as they seem.

In short, we do the work, so you don't have to. We speak to CPU vendors and find those special commands that make atomic actions work on 603, 604, x86 and other CPUs. They aren't always obvious, and usually require assembly coding. Fine grained locking is typically something you do in the kernel space; in user space, you're better off with the semaphore and Benaphore techniques.

Armed with a locking mechanism, what can you do? What good are they anyway? It seems they will just slow down your application.

Locking mechanisms are the most fundamentally useful techniques to use in a multi-threading, multi-CPU environment. If you are new to all this, then I would recommend some reading: "Object-Oriented Multithreading Using C++" by Cameron Hughes and Tracy Hughes (Wiley). This is not a book on doing multi-threaded programming on the BeOS, but it does cover many of the features, concepts and techniques common to any multithreading environment.

This refers, of course, to our latest BeOS release, DR 9.1, also known as Preview Release 2 (or PR2). If we go by the conventional wisdom of numbering conventions, since the "1" numeral is on the right hand side of the decimal point, this is a minor release. We know how this very convention keeps being abused for obvious marketing reasons, or more tortuous contractual ones, but, in our case, we don't mind the label.

One could summarize PR2 as the product of things we shouldn't have done, bugs, or things we should have done, features that didn't quite make it into the original Preview Release (PR1), such as, but not limited to, better handling of HFS volumes or the 3D kit. This doesn't mean we're not happy and proud of this latest release, we feel indeed it is a nice ".1" release, but, on the other hand, we're just doing what we're supposed to do.

The Preview Release was a risky effort, entailing many internal changes in the foundation of our OS, the new 64-bit file system being the most visible one. As a result, we were late by about 6 months, not an uncommon occurrence, but not an excuse either. With this in mind, one piece of good news regarding PR2 is we're back on track, correcting problems and adding features on a more regular basis.

As always, what we think of our work matters only very little. The verdict is in the hands of developers and early adopters. With PR1, we saw the beginning of commercial BeOS applications being shipped and sold. We hope PR2 will make life easier for our partners and customers and will generate the most precious commodity in our business, positive word-of-mouth.

Speaking of which... We owe thanks to all developers and users who gave us feedback after PR1 came out. Their comments, positive and negative, have given us information and motivation for the improvements, visible or not, you'll find in PR2.

As usual, we're nervous when a new release comes out: Have we overlooked some obvious problem, are we causing incompatibility grief to our developers, in our eagerness to correct problems have we caused more damage? We'll know very soon and, if need be, we'll post updates on our site.

From now on, our focus is on the Intel release and on helping BeOS developers test that version as soon as practical in order to open the gates to this bigger market in the most effective fashion for all of us. This is a new set of challenges. We realize there is more to the Intel world than a new instruction set, but we look forward to the task nonetheless.

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.