|
Be Newsletter
Issue 42, September 25, 1996
Table of Contents
Be Demo Tour: BeBox Demo in Texas!
Be, Inc. is coming to Austin and Houston for three meetings
in October. We'll demonstrate the BeOS(TM) running on the
BeBox and on PowerPC-based Macintosh personal computers
built by Power Computing, Inc. Two representatives from Be
will be available to talk about future plans and to answer
technical questions.
- October 1, 1996
HAL-PC General Meeting, Houston, Texas
Tuesday, Ocrober 1, 1996
Location: George R. Brown Convention Center (see
http://www.be.com/events/schedule/index.html for details).
- October 2 & 3, 1996
University of Texas-Austin Campus
Wednesday, October 2, 1996, 7:00 pm
Thursday, October 3, 1996, 7:00 pm
Location: Taylor Hall 2.106 (2nd floor, room 106). Taylor
Hall is on the corner of Speedway and 24th.
Maps of the UT-Austin campus are available from the Be web
site, for both an overall view and a close-up of the area
surrounding Taylor Hall.
REGISTRATION FOR BE DEMO TOUR EVENTS: E-mail
bedemotour@be.com to register for any event. Please tell us
your name, the names of the people coming with you, and the
meeting name (Houston, Austin Wednesday, or Austin
Thursday). Admission for unregistered guests will be on a
first-come, first-served basis.
BE ENGINEERING INSIGHTS: I Quit!
By Steve Horowitz
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.
BE DEVELOPER TALK: subAtomic Software
By Delbert Murphy
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(TM).
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
BE MARKETING MUTTERINGS: The Joys and Perils of Growth
By Alex Osadzinski
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.
The User's Perspective
By Jean-Louis Gassée
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 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: 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
- ----WEEK 4-------------
Subject: How are we supose to do this?
More game designer talk. A couple of solutions to the
graphics/physics clock rate problem were suggested and
debated.
- ----WEEK 4-------------
Subject: AES/EBU
Although the Crystal codec that comes with the BeBox is
good, some folks want (or need) professional audio gear. It
was suggested that Be be encouraged to include a Digital
Audio Interface (DAI). It was countered that that might be
an overly expensive solution to a problem that only a few
developers are really affected by.
- ----WEEK 2-------------
Subject: PPP in DR8
AKA: Help with PPPlease!
AKA: PPPuh-leeeze...
Why doesn't PPP work in DR8?...
THE BE LINE: Brad Taylor of Be posted a message that
described the difference between DR7 and DR8 PPP (and
postulated advancements for DR9). He also gave instructions
for setting up your modem connection to fit in the DR8
world. You can read a copy of this message on the Be web
site: http://www.be.com/developers/PPPinDR8.html
- ----NEW-------------
Subject: Application Architecture
AKA: Application Template
These two threads discussed the desirability of application
framework classes/tools/paradigms/definitions for viewing
documents (where you can have more than one view onto the
same document, or where a document is actually a collection
of "subdocuments"), scripting, plug-ins (what Be calls "add-
ons"), and the like.
- ----NEW-------------
Subject: Another OpenFile panel scenario
Why don't file panels display more intelligence? It was
suggested that the Browser allow add-ons for the Open and
Save panels.
- ----NEW-------------
Subject: D'oh! Pulse
A couple of questions:
- Why does pulse no longer show
memory usage?
- Is Stellar Pulse (in the Live3D
application) a CPU monitor?
Answers (as correctly offered by our readers): - Because
folks were often confused by the memory usage statistics.
- No, it runs stellar data collected by Benoît Schillings,
a 16th century Belgian astronomer.
|
