Be Developer Services

Free Resources

BeIA FAQ

BeIA Evaluation

Partner Program

Join

Partner Area

Issue 5    July 5, 2000 Be Press Releases June 26, 2000 New BeIA Software Platform to Incorporate Gemplus Smart Card Readers return to top This column will return in the next issue. return to top Jean-Louis Gassée Column by Jean-Louis Gassée No column this week from the jet-lagged JLG. return to top Business Development at Be By John Moon, VP I.A. Business Development Let me introduce myself -- my name is John Moon. I joined Be in April to take responsibility for Business Development. Even though I have been on board for only three months, I feel as if I've been here from the start. I remember when Steve Sakoman and JLG were developing their business plan. Before talking to the financial community and OEMs they asked various friends for opinions about their vision. I was privileged to be one of those friends. The notion of a sophisticated operating system rising over the primordial OS stew (DOS, Mac, Windows, UNIX, whatever) is truly exciting. BeOS is not only a pleasure to work on for developers; it also makes life better for the rest of us. The same kind of developer empowerment, coupled with user friendliness, is now part of BeIA. When I heard what was happening at Be I was intrigued because I knew of no one else approaching Internet appliances from such a media-centric perspective. When I contacted Jean-Louis after not having seen him for a few years, my antenna should have shot up when he said, "let's do lunch -- I want to talk about something." The last time that happened was years ago when I worked for him at Apple and he gave me a two-hour lecture outlining his vision for Apple's peripherals. What he wanted to discuss at the second luch was Be, so between slurps of noodles, he told me what he, Steve, and Lamar Potts were up to. Once again ther vision sounded good to me. I believe that BeIA and the Be developer community give us some unique opportunities. I see my role as establishing the complimentary relationships which are needed to deliver this uniqueness to clients in an Internet environment. Many relationships will be made in order to deliver services to the end user. I am looking to add recurring revenue opportunities to our licensing model. Basically, my team is looking to add value to the BeIA offering. The idea is to provide seamlessly integrated services. We are currently looking at several relationships that meet this criterion. I hope to be back in a few weeks to tell you who, what, and when. What I can say at this point is that BeIA has the potential to fundamentally change the way people interact with the Internet. Our multimedia capabilities will play the key role. For example, it's well known that retention on the part of TV viewers is 30 times greater than for Web banner viewers. The cyber-cacophony of a portal screen leads to a less than 1% retention rate. You can guess what the connect (purchase) rate is. BeIA-powered devices, with their multimedia capabilities, might vastly change things. return to top Murphy's Laws of Multithreaded Programming by John Dance, Software Engineer / Applications As we finish up our version of PersonalJava for BeIA, we're happy to report that the vast majority of the applets out there run well with our Java implementation. Unfortunately, there are a few that have problems. We recently received a bug report "Scrolling applet at www.cant_say_but_I_would_like_to.com locks up browser." Well, we take a bug report like this one pretty seriously. Locking up the browser isn't very friendly, especially when the browser is the the UI for the machine. The applet in question implements a "headline" scroller and allows the user to select a headline to navigate to more information about that headline. Since the headlines are constantly scrolling by, moving the mouse into the applet's view causes the scrolling to stop. This allows the user to select the desired headline. Then when the mouse leaves the view, the scrolling is continued. I was able to reproduce the bug and found that a key system resource (the Window lock for the browser) was being held by a thread that was...suspended. This is not good. Using various handy debugging means, I looked at the source to the applet. There were two threads busy working away. Thread one was busy running the following loop: (Warning... Java code below. Just pretend it is C++.) public void run() { try { Thread.sleep(interval); } catch(InterruptedException interruptedexception) { System.out.println("Error"); } paintImage(noSelection); repaint(); moreComputations(); } Meanwhile, thread two was handling user events. It handled the mouse entering and leaving the view like so: public boolean mouseEnter(Event event) { thread.suspend(); paintImage(currentSelection()); repaint(); return true; } public boolean mouseExit(Event event) { thread.resume(); paintImage(noSelection); repaint(); return true; } By way of background, Java threads are mapped to native threads by our JVM. Any Java drawing operation is layered on top of an Interface Kit drawing operation, so a Java drawing operation implicitly must acquire a BWindow lock. With that information, do you see the problem? It wasn't in our JVM, it was in the applet. Suppose thread one happens to be in the process of drawing to the window so that it holds the window lock. At this point in time, the mouseEnter is called and thread one suspended. Unfortunately, in processing mouse events as the mouse leaves the window, the system needs the window lock and so it blocks waiting for it. But thread one holds that resource, and it is suspended. Deadlock! While the problem with BWindow lock could be handled internally in Thread.suspend(), the general problem remains. Thread.suspend() is never a good method to call directly because the suspended thread could be holding onto an important resource. In fact, Sun has deprecated Thread.suspend() Java2. (See <http://java.sun.com/j2se/1.3/docs/guide/misc/ threadPrimitiveDeprecation.html>). How does this apply to Be programming? The same rules would hold true of calling suspend_thread(). Calling suspend_thread() when you don't know the state of the thread can potentially cause deadlock just as easy as Thread.suspend() does in Java. How would you fix this problem? The key is to get the threads working together. Using the Java threading primitives, it took about 5 minutes to rework the code to fix this problem. Here is the new code: public void run() { try { Thread.sleep(interval); } catch(InterruptedException interruptedexception) { System.out.println("Error"); } pauseThread(); // see if the user wants scrolling to pause paintImage(noSelection); repaint(); scrollUp(); } public boolean mouseEnter(Event event) { handleStop(); paintImage(currentSelection()); repaint(); return true; } public boolean mouseExit(Event event) { handleStart(); paintImage(noSelection); repaint(); return true; } synchronized void handleStop() { stopPainterThread = true; } synchronized void handleStart() { stopPainterThread = false; notify(); } synchronized void pauseThread() { while (stopPainterThread == true) { wait(); } } The pauseThread method checks to see if stopPainterThread is true. If so, it waits until someone does a notify. The mouseEnter just sets stopPainterThread to be true so the main thread will stop and wait. The mouseExit sets stopPainterThread to false and then notifies the waiting thread. The loop on stopPainterThread makes sure that mouseExit and then mouseEnter didn't happen before the main thread got going again. Remember Murphy's law of multithreaded programming would state that any wild thread sequencing that you think can't happen will happen very frequently, if not every time. Notice that all these methods are now synchronized. A synchronized method in Java is just like each method grabbing a common BLocker. Now the question might be...how would this type of synchronization be written using the Be APIs. The following might be one of multiple possibilities. It follows the Java style. Quickly sketch your own design before you read on: BLocker painterLock("stateLock"); void HandleStop() { BAutolock lock(painterLock); stopPainterThread = true; } void HandleStart() { BAutolock lock(painterLock); stopPainterThread = false; resume_thread(painterThread); } bool GetStopPainterFlag() { BAutolock lock(painterLock); return stopPainterThread; } void PauseThread() { while (GetStopPainterFlag() == true) { suspend_thread(find_thread(NULL)); } } Since suspend_thread() doesn't automatically release painterLock like the Java wait() releases the class monitor, we need to be careful not to suspend ourselves holding the painterLock. Otherwise we've traded a potential deadlock for a deadlock that would happen every time the mouse left the view. The key point is that one thread is not stopping or suspending another thread in any random position. Rather, it is suspending itself in a known state without locks held. Murphy's second law of multithreaded programming would state that if you stop a thread in a random position, the position chosen most often is the one holding the most locks. There are, of course, other methods to synchronize the threads. Other solutions might include using a semaphore, or atomic_add. Can you sketch out a design using an alternative style? Have your threads work together so you don't have to find more of Murphy's laws in multithreaded programming. You can find additional information and examples in the Be Book. <http://www-classic.be.com/documentation/be_book_r32 /The%20Kernel%20Kit/Semaphores.html> and <http://www-classic.be.com /documentation/be_book_r32/The%20Kernel%20Kit/Threads.html>. A good book on multithreaded programming (with examples in Java) is "Concurrent Programming in Java: Design Principles and Patterns," by Doug Lea <http://www1.fatbrain.com/asp/bookinfo /bookinfo.asp?theisbn=0201310090>. return to top Statements contained in this Newsletter that are not historical facts are "forward-looking statements" including without limitation statements regarding the demand for, future market penetration and market acceptance of BeIA and BeOS, the shipment dates of Be's products, and the future operating results of Be Incorporated. Actual events or results may differ materially as a result of risks facing Be Incorporated or actual results differing from the assumptions underlying such statements. Such risks and assumptions include, but are not limited to, risks related to competition, market acceptance and market penetration of Be's products, ability to establish and maintain strategic relationships, the benefit of Be's products to OEM and Internet appliance manufacturers. the continued availability of third party BeOS applications and drivers, and the ability to establish and maintain strategic publishing relationships. All forward-looking statements are expressly qualified in their entirety by the "Risk Factors" and other cautionary statements included in Be Incorporated's Annual Report on Form 10-K for the year ended December 31, 1999, and other public filings with the Securities and Exchange Commission. The BMessage Copyright (c) 2001 by Be, Inc. All rights reserved. Be, Inc. 800 El Camino Real, Suite 400 Menlo Park, CA 94025 Tel: (650) 462-4100 Fax: (650) 462-4129 Web: http://www.be.com/ Be, BeOS and BeIA are trademarks or registered trademarks of Be Incorporated in the United States and other countries. Other brand product names are registered trademarks or trademarks of their respective holders. All rights reserved. The BMessage is sent to subscribers of one or more of the Be mailing lists. For more information about subscribing/unsubscribing, see the Be web site: http://www.be.com/world/mailinglists.html. The Be web site also offers a complete set of current and back issues of Be Newsletters: If you have any comments about The BMessage, please e-mail them to:newsletter@be.com.

About Be, Inc. | Be Products | World of Be | BeOS Support | Jobs | Developers | Press | Partners | Investors

Copyright © 2001 by Be, Inc. All rights reserved. (Legal Info)
Comments, questions, or confessions about our site? Please write the Webmaster!