|
Be Newsletter
Issue 11, February 21, 1996
Table of Contents
BE ENGINEERING INSIGHTS: BE
CAREFUL
By Cyril Meurillon, Software Engineer
C++ makes programming applications fun and efficient through
the use of objects. Multithreading operating systems make
computers more responsive because applications can be
divided into independent tasks. The mixing of the two is
natural in modern computers such as the BeBox.
In the programming model of the Be Operating System(TM),
applications spawn threads that create and share global
objects such as windows and views. This is both very
powerful and dangerous. The different threads of an
application are running simultaneously, and one of them may
destroy a shared object at any time. The other threads will
keep trying to use the destroyed object, which is
problematic, unless special precautions are taken. There are
two solutions to the problem.
The first solution is to use unique IDs as object
identifiers. The validity of the object is checked whenever
it is used, and an error is returned if the object has been
destroyed. It is then up to the thread to deal with the
error. Unfortunately, C++ uses pointers as object
identifiers, which aren't unique IDs as they may be
recycled. This is consequently not a solution that can be
considered when programming for the Be OS(TM).
The second solution is somehow to synchronize the threads
whenever a shared object is destroyed. For example, one can
think of a scheme where threads receive a death
notification, so that they can remember not to use the
object any more. This is the kind of solution that a Be
developer would adopt. Note that the implementation of such
a scheme is the entire responsibility of the developer. But
here are a couple examples.
Let's start with the Database Kit. BRecord objects
implicitly refer to the BDatabase object associated with a
volume. There is only one instance of this BDatabase object
per team, which is shared by all the threads of the team.
Everything is fine until the volume is unmounted. When this
happens, the main application thread is sent a synchronous
notification message, and then the BDatabase object is
destroyed. But what about the other threads of the team? If
one tries to instantiate a BRecord given a record_ref after
the database has been destroyed, it is safe. The BRecord
constructor will simply report an error. A record_ref is a
unique ID that can be checked when a BRecord is created. But
if the thread has already created the BRecord object when
the database is destroyed, then things get more complicated.
A BRecord object may stop functioning any time of its life,
because the underlying BDatabase object goes away. You can't
assume any BRecord method call will succeed, even after the
object has been created and the record read in. Errors must
be checked and dealt with absolutely everywhere. This makes
programming especially difficult and unpleasant -- something
C++ isn't supposed to be.
What's the solution? The Browser solves this problem in an
interesting way. When the main Browser thread receives an
unmount notification, it synchronously broadcasts it to all
its windows. On reception of this message, all the Browser
window threads can safely dispose of BRecords associated
with the volume going off-line. This ensures that a thread
can safely use a BRecord during each cycle through the event
loop.
We see that great care should be taken. The only safe use of
a BRecord object is in the context of an event-driven
thread. BRecord objects can't be used in a thread that isn't
event-driven (for example, a compute-intensive thread),
because the underlying BDatabase object may be destroyed
asynchronously.
Now let's consider the Application Kit. The BLooper object
offers the Lock() and Unlock() methods so different threads
can share an object safely. Whenever a thread accesses a
BLooper, it must lock it. The thread can unlock it when it
is done with the access.
Let's imagine two threads, A and B, sharing a BWindow object
(which derives from BLooper). Thread A destroys the window
and then thread B wants to access it. B invokes the Lock()
method on the destroyed window (note that Lock() isn't a
virtual function). The method invocation is simply a
function call. No virtual table lookup is necessary, which
is fortunate because the object doesn't exist any more. But
you must admit that the idea of invoking a method on an
object that doesn't exist any more is a little troublesome.
The first thing that Lock() does is to safely check whether
the 'this' pointer is a valid BLooper object. If it isn't,
Lock() reports an error. If it is, Lock() carefully locks
the object.
All this seems perfectly safe. But it isn't. Lock() catches
all cases of invalid pointers. But what if the pointer
becomes valid again? Pointers aren't unique IDs, and one can
reasonably think of a new window being allocated at the same
place as the old one. The new window would get locked, while
the thread wanted to lock the old one. We see that Lock() is
successful at serializing all accesses to a shared BLooper
as long as the object isn't destroyed.
The solution, once again, is to synchronously broadcast a
message to all the threads of the team to notify tell them
that the object has been destroyed. This prevents the use of
such objects in threads that aren't event-driven, but allows
safe sharing of objects among the different threads.
BE DEVELOPER PROFILE: The
Mipsys GeekPlayer
By Michel Safars, CEO, Mipsys-France
The company I run, Mipsys, specializes in videoconferencing
software and industrial data acquisition and treatment. We
also work with Echelon's LonWorks field bus technology in
industrial and building automation. We do a lot of
engineering development but we also produce products for
other companies and for Mipsys itself.
I first met Jean-Louis in the USA back in the early 1990s to
talk about "la pluie et le beau temps" [the rain and the
good times]. A few minutes later, I was very surprised to
see him leave the room and come back with an NDA
(nondisclosure agreement).
I didn't want to have any confidential information at first,
but Jean-Louis insisted. So I signed up.
He showed me the BeBox project. I was very happy to see that
most of the best technologies were already in the machine,
as well as some very smart operating system features, such
as multiprocessing, an integrated database, and real-time
capabilities.
Fourteen years ago, I started my computer life with the
Apple II and I remember how useful the joystick port was for
small home or laboratory experiments in many fields. So I
offered to add some built-in data acquisition capabilities.
Jean-Louis immediately agreed to the idea. But at that time,
Be discontinued the Hobbit-based BeBox and started
redesigning the BeBox with PowerPC processors. By
redesigning the machine, it was now possible to include the
GeekPort(TM), a set of parallel and analog input/output
connections. Including the GeekPort in the machine would
allow any user to have all types of functionalities that
were particularly useful for home automation, laboratories,
or geek use!
Now that the hardware was going to be done directly by Be,
Jean-Louis called me and asked me to think about software to
control the GeekPort.
I had been dreaming of software for home automation and
independent geek use for a long time. For years I had
observed software evolving and becoming more user-friendly,
but it happened slowly. Just as the Mac OS compared to its
predecessors, I wanted something really more friendly. This
was certainly not easy either to imagine or to develop.
With the help of Raphael Moll and Olivier Coudert, Mipsys
invented a new software environment we named GeekPlayer.
GeekPlayer is a special BeBox software environment for
easily developing applications that control all kinds of
experiments. We were the very first European developer to
work on the BeBox, and our whole team is proud of that,
because we truly believe the BeBox will become a widely used
and useful computer. In this adventure we always did the
best we could. We appreciate this creative and constructive
way of doing business.
By joining BeBox developers you will certainly find one of
the best ways to create, invent, and do good work. I also
encourage European developers to participate actively and
develop new original applications that take advantage of the
BeBox.
I benefit from writing this article to say that we work in
the videoconferencing field as well. If you are interested
in working with us, just call me or send me e-mail at
mipsysad@imaginet.fr.
Have fun, and let the creative spirit be with you.
GeekPlayer will soon be available on the Net!
Java
By Jean-Louis Gassée
"What about Java? What do you think about it and what are
your plans for it?" I'm often asked these questions on-line
and in person and this is a place to begin answering
them.
First, programming languages. I'm agnostic -- or practical.
Currency, for me, is the big determinant. If the language is
in wide circulation, well-supported by toolsmiths,
well-abused by programmers, I embrace it wholeheartedly. Do
you think C++ is lovable? Unless you're into SM (Software
Masochism), probably not. But it has currency. At this stage
it has become the lingua franca of our business -- just as
English has become the world's communication vernacular. Do
we think of BASIC as an elegant language? In the old Sears
and Roebuck sense of style, perhaps -- I mean this in the
comfortable, familiar, no-nonsense style of the old catalog
of tools. Microsoft understood this and were very clever in
making Visual Basic such a success.
I've been involved in decades of language arguments. Always
interesting, even more so if you understand my culture of
birth, where we enjoy nothing more than an intellectual
argument -- about wines or movies, or about APL, ADA, and
Pascal. We even have existentialist cab drivers. But in the
end, one set of circumstances or another, English colonies
or Bell Labs and UNIX give a language wide circulation and
momentum.
So what about Java in this frame of reference? It's mostly
good news. I don't know if we should equate Sun with Bell
Labs and, if I can twist the metaphor a little bit, it looks
like there is a revolt afoot against the United Kingdom of
Microsoft. I sense a great deal of the energy propelling
Java as being anti-Microsoft. It's probably unavoidable now
that Microsoft's size and power make the polarization easy,
but it shouldn't be confused with what Java does for
programmers and users -- even if one of Java's touted
benefits is avoiding the dire consequences of a one-standard
world dominated by Microsoft. I come from a company that
made one great ad in 1984, introducing the Macintosh as a
way to break Big Brother IBM's domination. And yes,
recently, some wags have pasted Bill Gates' picture into the
ad. Great ad, one of the greatest. It only helps a little in
a long, complex battle.
So what about Java itself and the strategy to make it the
Web's C++? It looks promising. Close to home, Metrowerks
will ship Java tools on the next CodeWarrior CD and there
are several efforts afoot to write a Java interpreter on the
BeBox. The known limitations of Java are being addressed.
Just-in-time compilers will deal with some of the
performance issues, and enterprising programmers are already
perverting the "standard," producing deviant extensions.
Just as with human languages, barbarisms and neologisms are
a sign of acceptance; people's desires are channeled into
it, unnatural acts result in a robust life form, as in the
Greek roots of the word "hybrid."
A few things remain to unfold. One of them is Sun's real
plans. For many years I have admired Sun's skills at
ideological warfare, at getting airtime, saying one thing
and doing another. For instance, Sun has been very good at
preaching the open systems gospel. In the end they have a
proprietary offering of hardware and software, which they
call an industry standard. When I see them promoting Java as
an industry standard and announcing a little later they'll
produce hardware to run Java really well, I'm interested.
Are they using their considerable persuasive powers to
promote a standard, channel into it the energy of many, with
the intent of controlling their own "better" version of it?
Come to think of it, isn't this the game Netscape plays with
HTML and Navigator?
The other factor still to play out is Microsoft's OCX (OCs
as they're newly called, standing for OLE Controls), objects
-- or applets in the Windows/OLE world. Now, Java's most
compelling feature is platform-independent distribution of
applications over the Net, a very attractive idea. What
Microsoft will say is: OK, in theory you can do that with
Java (to the best of my knowledge, they still haven't
executed the letter of intent to license Java) for 100
percent of the machines connected to the Net. But in
practice, you can do that with OCs for 90 percent of the
clients, without having to trade off simplicity or
performance for the other 10 percent. An interesting
argument, one that only reinforces the fears of Microsoft
domination -- but one that needs consideration
nonetheless.
Here at Be, we all look forward to the emergence of Java as
a successful independent standard, more like the Internet
and C++, adopted by many and controlled by no one.
Be There! First Firebug
User's Group Meeting in the Seattle Area
Don't forget!
The First Firebug User's Group meeting will be held in the
Seattle area on Saturday, February 24, 1996, in Bellingham,
Washington (midway between Vancouver Seattle).
If you're interested in attending (space may be limited),
send e-mail with the subject line "I Wanna C Be" to
Firebug@abiogenesis.com
and state how many people will be attending.
|
