One of the most common questions developers ask us is "How do I get my threads to quit safely without using kill_thread()?" There are many ways to do this, but the handiest method involves an acquire-with-timeout semaphore.

Consider this situation: You have two threads, a "master" and a "slave." The master thread spawns (and resumes) the slave, and is responsible for stopping it. The slave thread loops over a "critical section"; the only time the master can safely quit the slave thread is when the slave is outside the critical section.

The trick is for the master to detect when the slave is outside the critical section, at which point the master tells the slave to pop out of the loop. The slave, having departed the loop, can then perform any clean up it needs to do, and exit naturally (by reaching the end of its entry function). To do this, we create a semaphore to which both threads have access—for our example, we'll make it a global semaphore. Note that the semaphore is given an initial thread count of 1 (as expressed in the first argument to create_sem()):

sem_id  sync_sem;

master_thread()
{
   sync_sem = create_sem(1, "synchronization vulture");
   ...

Next, the master spawns and resumes the slave thread:

thread_id slave_thread;
slave_thread = spawn_thread(slave_func,
     "HeyIAmBusy", B_LOW_PRIORITY, NULL);
resume_thread(slave_thread);

The body of the slave thread's entry function (slave_func()) looks something like this:

long slave_thread(void*)
{
   /* Keep looping as long as we can
      acquire the semaphore. */
   while(acquire_sem_etc(sync_sem, 1, B_TIMEOUT, 0.0) ==
         B_NO_ERROR) {
      /* Put your critical section here. */
      ...

      /* Critical section done,
         now release the semaphore. */
      release_sem(sync_sem);
   }

   /* We're outside the loop; clean up... */
   ...

   /* ... and exit naturally. */
   return(B_NO_ERROR);
}

Notice that the slave thread uses acquire_sem_etc() with the B_TIMEOUT flag set and with a timeout value of 0.0. This means that the slave thread will keep looping as long as it can *immediately* acquire the semaphore. However, if the semaphore isn't available, the function *immediately* returns B_WOULD_BLOCK.

What happens when the master wants the slave to quit? The master thread can't blithely kill the slave (through kill_thread()), because the slave might be in the middle of its critical section. Instead, all the master has to do is acquire the synchronization semaphore:

acquire_sem(sync_sem);

This acquisition will block until the slave calls release_sem() after its current pass through the critical section. When the slave executes the acquire_sem_etc() function (in the loop predicate), the function will immediately return B_WOULD_BLOCK, which will cause the slave to skip the loop, clean up, and safely exit.

If the master wants to make sure that the slave is dead before it continues, it should call wait_for_thread() immediately after the acquire_sem() call:

long return_val;
acquire_sem(sync_sem);
wait_for_thread(slave_thread, &return_val);

Keep in mind that after all this, sync_sem's thread count is 0 (since it's been acquired by the master thread). Therefore, if you want to reuse the sync_sem semaphore, you'll have to release it first so the next acquisition will succeed.

Through a couple of modifications, you can use this technique so that the master thread can control any number of slave threads. You simply increase the semaphore's initial thread count (the first argument in the create_sem() call) to the number of threads (N) that need to be controlled, and then change the master's acquire_sem() call to this:

acquire_sem_etc(sync_sem, N, 0, 0);

This use of acquire_sem_etc() attempts to acquire the semaphore N times —in other words, once for each slave thread. Note that the call doesn't have a timeout (because the B_TIMEOUT flag isn't set): The call will block until all N acquisitions are affected. Thus, when the function returns, you're guaranteed that all the slave threads are outside their critical sections and are either standing on the other side of the Styx, or, at least, in the boat.

Hopefully this will help make your application design a little simpler when it comes to synchronizing multiple threads.

Greetings, from the inside of my hardware to the inside of yours.

My name is Delbert Murphy. By day, I write Smalltalk and C++ for a huge company that is obsessed with profit targets. By night, I chase my dream: Writing commercial software for the BeBox, as I put the pieces together to form the subAtomic Software product line.

I've always thought in pictures and graphical patterns—I'm just an analog fellow in a digital world. I remember faces, not names. When I need the information operator, I dial: center-button, center-button, center-button, upper- left-button, upper-center-button, upper-left-button, upper- center-button (you may know it as 555-1212). I have a good deal of trouble using a rotary phone, because I've forgotten the circular shapes for everyone's phone numbers.

Imagine my delight when I first saw the Be web site. Here was a computer that I could (probably) afford, that had enough horsepower to do graphics justice—and still have some processor power left over to handle my other passion: Artificial intelligence. I recognized Be's real-time and embedded systems ancestry, the keys to getting the BeOS right.

The basis for the subAtomic Software product line is the fusion of graphics and artificial intelligence in real time. When you have a really tough problem to solve, do you draw a picture? When you design your BeBox application, do you draw an object model on paper? Perhaps a static object diagram first, and then object interaction diagrams to lay out different user scenarios? Sure you do.

What I am endeavoring to build is a workbench on which you graphically lay out your ideas and see how they fit together. And more. I want the workbench to suggest alternative arrangements of ideas, help you draw conclusions about the information you have so far, help you relate ideas in ways you hadn't considered. I envision a cross between a high-end CAD package for ideas and a Zen master. I call it the fusion ThoughtBench™.

The fusion ThoughtBench that I will release this fall will only be the first step towards a lofty goal. I have started out simply: Getting the underlying object model right first, making sure to separate the ideas (which are longer-lived and probably more static) from the representations of the ideas (which can change according to your chosen perspective). The first release of the product will represent ideas and their relationships, will capture information about the ideas, and be able to produce documents—such as articles, resumes, presentations -- from this information.

The next release will incorporate a new perspective: Object modeling and some rudimentary C++ code generation. Another release will incorporate another perspective: Axioms, theorems, and proofs—probably beginning with Euclidean geometry. A further perspective, in a further release: Letting you define a problem space (say, the stock market) and mapping functions (stock valuation algorithms), and a solution space (buy/sell/hold). The perspectives are only limited by our hardware and our imaginations (or is that hardware too?).

[Many musings on Being and Nothingness deleted by the author.]

I welcome suggestions, encouragement, or philosophical reflections at: drmurph@gnn.com

There are many things I enjoy about working at a small start-up company like Be, some of them minor, some of them significant. I like the fact that the stapler that's left on top of the photocopier doesn't disappear and that whoever uses the last staple refills it. I like knowing everybody in the company. I like spending less than an hour a week in regular internal meetings. I like never having to attend facilitated offsite cross-functional interdivisional long- range ISO9000 task force planning paradigm shifting premeeting presentation planning preparation briefing meetings with a ropes course icebreaker.

And I like growth.

Growth is an inherent attribute of a successful start-up. Without growth, a company withers and dies. With growth, the things that you do change from day to day and there is a perceptible and quantifiable increase in the level of activity and excitement. Growth is fun, but it brings with it some challenges; the primary challenge is to keep up with the growth.

Be is growing fast right now, whether you measure it in number of application developers, number of BeBoxes sold, or number of column inches of press. We're enjoying the fruits of our labors, but are also concerned that we're not always keeping up with that growth. I want to share those concerns with you and tell you what we're doing to address them.

As we've mentioned before, application developers are our lifeblood. Their success is our success, and so we want to do everything possible to recruit developers to our exciting new platform and retain them with excellent support and excellent business opportunities on the platform. There are two areas where our growth has caused us to be less responsive than we'd like: Processing new developers into our developer program and responding to developer questions through our developer tech support group.

I apologize to anyone who's been kept waiting. We're addressing the issue by carefully hiring people to handle the increased workload. So far, we've hired three people into the developer support area, two of whom are now on board with a third joining next week. We're still interviewing candidates and will try to keep hiring in line with the growth of our developer program .

We do occasionally hear of e-mails to our developer support group or application forms to enter our developer program remaining unanswered for days or weeks. This is a bug; an e- mail to the developer support group should always be answered, or at least acknowledged, by the end of the following work day, and an application form to enroll in the developer program should always be acknowledged within four working days. If you don't hear back, please e-mail me (alex@be.com) and I'll investigate. We'd hate to lose a friend because an e-mail went astray or because someone hit the delete button by mistake.

On another topic, I've received quite a few calls and e- mails from people who've seen our announcement that we've shipped the DR8 version of the BeOS and who want it for their PowerMacs. Allow me to clarify: DR8 currently runs only on the BeBox, and we've not yet released a version of the BeOS for the PowerMac. We expect to make an early version of the BeOS for PowerMac available to our developers later this year, with a more general release early next year. Stay tuned to this newsletter and our web site for more news.

In the early years, Hewlett-Packard was known solely for its measuring instruments. Life was easy. Engineers designed for engineers, for the guy at the next lab bench, the saying went. That practice couldn't even be called a philosophy, it was what HP did instinctively. Their first pocket calculator, the HP-35, was the result of the same libido. Bill Hewlett wanted an electronic slide rule that fit in his shirt pocket. It was an instant best-seller, a high-tech product right on its high-tech target. The story, perhaps apocryphal, is that the HP-80, the first financial pocket calculator, was designed because David Packard wanted to do sophisticated bond price calculations. It, too, was well received by its intended users. And the margins were so "nice" it was the single highest contributor to HP's profits for a while.

There are numerous reasons to be wary of such an approach. Many will find it self-centered. How dare you represent yourself as a typical user? Indeed. Many companies prefer market research and focus groups as a source of insights into the customer's needs and wants. This approach has its problems. It works best on derivative, incremental products, but it can be counter-productive when the audience is faced with unknown, previously unthinkable notions for which it did not have a pre-existing vocabulary.

In December 1982, ask the "man on the street" the personal computer he wants, he'll describe a better Apple /// (!?) or a faster, smaller, cheaper IBM PC. Show the same individual a Lisa in January 1983, the reaction will be:

"That's what I want!"

"But, but, that's not what you told me last month."

How could the customer think of mice, menus, windows, and bitmapped screens in December 1982? Focus groups can also be abused and lead to risk-adverse mediocrity. In his book "Making Movies" (highly recommended), Sydney Lumet has choice words for movie endings designed by the marketing departments of Hollywood studios—even if he honestly recognizes the system leaves little choice but to do those tests and to make those changes.

Thanks to the Internet and Altavista, I got in touch with Wiley, the creator of "Non Sequitur" cartoons. Through a dealer, Markomics (www.markomics.com), I bought the original of a Sunday "Non Sequitur" cartoon: Wiley drew Michelangelo on a scaffolding in the Sistine Chapel. On the ground, a bishop looks up from a scroll and states: "Personally, I think it looks OK, Michelangelo, but the focus group says it needs more mauve..."

In Be's case, when we started the company in late 1990, what would the focus group have said? Another OS, who needs it? Even today, where the opportunity for fresh system software on the PowerPC appears a little less difficult to assess, no less an authority than Dick Shaffer, of Technologic Partners, reflexively noted: "It would give Apple what it does not need: Another operating system that has no applications." Some of the statement is in error. Especially the "give" part. As for the applications, we'll soon meet our milestone of 1,000 BeBoxes in developers' hands.

So far, these developers have been our target users. Most of our efforts have gone into making the BeBox and the BeOS attractive for this audience. It's not too difficult for the Be engineers to understand the perspective of their early clients. As applications start to emerge, we also put ourselves in the user's shoes. Shichiro Irimajiri, once the head of Honda of America, and now back in the game, so to speak, as the head of Sega of America, used to worry Honda needed to shift its focus. "We used to build cars for ourselves, but we are getting old and if we don't watch it, we'll end up building Cadillacs and we'll miss the new customers." In our case, we're lucky the normal progression of our business takes us first to the early adopting lunatic fringe first. The shift in perspective will become harder when we approach the mainstream. We still have much to do and much to prove to reach that stage—and it will be a nice problem to have.

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.

A lot of mail this last week was about the DR8 upgrade; there were both commendations and... suggestions. Rather than summarize the various DR8 threads individually, we'll simply thank you for your recognition of the DR8 improvements, and assure you that we're trying to fix the bugs that you've found and reported.

A gentle reminder: If you find a bug in DR8, please report it through the Bug Report form in the Developer section of the Be web site: http://www.be.com/developers/bugform.html