Be Developer Services

Free Resources

BeIA FAQ

BeIA Evaluation

Partner Program

Join

Partner Area

Issue 17    January 17, 2001 Be in the News January 16, 2001 Q&A: Jean-Louis Gassée, CEO Be Inc., SiliconValley.Internet.com January 15, 2001 Sony's Un-PC, Interactive Week January 14, 2001 Interview: Jean-Louis Gassée - Part 2, BeGroovy.com January 11, 2001 BeIA at CES... My Impressions..., IA Zone January 9, 2001 Connected Entertainment Hub Platform Available, allNetDevices.com January 9, 2001 Be Plucks HARP to Target Hi-Fi World, The Register January 8, 2001 Sony Unveils Consumer Web Appliance, Business 2.0 January 8, 2001 Sony Unwraps New Net Appliance, PC World.com January 8, 2001 Sony Lineup Takes PC In New Direction, Techweb January 8, 2001 Sony e Villa Sports Clean Display, TechTV January 8, 2001 Sony trots out Web-browsing eVilla, CNET.com January 8, 2001 Interview: Jean-Louis Gassée - Part 1, BeGroovy.com January 1, 2001 How BeOS Does High-Performance Media, Byte.com December 22, 2000 Scot Hacker shares his thoughts on Adamation, BeOS, RipEnc and BeIA, homenetappliance.com December 15, 2000 Be Maps Plans for Internet Appliance Management, SD Times Be Press Releases January 18, 2001 Be and TASCAM Announce the Selection of BeIA as the Operating Platform for Future Pro-Audio Products January 8, 2001 Be Offers Home Audio Reference Platform for Internet-enabled Home Stereo Component January 8, 2001 Be Inc. and Music Browser Inc. Team to Offer Retailers Unique Broadband Music Listening Stations January 6, 2001 Be Announces Development of BeIA Client Software for Sony's New e Villa Network Entertainment Center January 2, 2001 BeIA Supports Full Line of HP Deskjet Printers return to top Transfer of Power by Jean-Louis Gassée, CEO and Chairman Two years ago, Steve Sakoman and I went to CES. For the most part, it was a boring succession of nearly identical booths "manned" by bored individuals. "This year, the fashionable face plate color is titanium" is only a slightly oversimplified summary of the event. There were two exceptions, however. One was the time-warp section for high-end audio, featuring "premium" Russian 12AX7 triodes and oxygen-free, oriented crystals with specially braided copper cables for a markedly better sound -- at least at the cash register. The other interesting booth was the Microsoft PocketPC display, with a videotaped demo that was probably a rehearsal for the anti-trust trial. While the tape rolled, the demo-meister made the right gestures on the non-functional device under a camera supposedly feeding the display above his head. It was a good demo. This year the cab drivers, always well-connected, complained that COMDEX attendance was down from previous years. CES, on the other hand, was up. I don't know what happened to the Russian triodes but, yes, the main show was much, much more interesting than ever before. It seemed as if the financial and emotional energy had moved from COMDEX to CES, and the creative energy and investments were moving from the PC to the consumer electronics space. To put that another way, it appeared that consumer devices were reaping the dividends from two decades of technology and infrastructure investments in the PC space. We were very happy, of course, to see our work for Sony's eVilla come to light. eVilla, along with another BeIA-powered appliance from Qubit received awards at the show -- a good way to start 2001. And another reason to remind ourselves that we still have much to do and much to prove. We also introduced our Home Audio Reference Platform, HARP, for Internet-enabled home stereo equipment. The Sony booth was swamped and eVilla got great reviews. We had many interesting conversations around our presence at the Real Networks display, and our private suite at the Bellagio was booked for meetings all day long. Still, if the show's overall context hadn't shown a transfer of power and energy from the PC business to the consumer electronics space, I wouldn't be as happy. For instance, it now looks as if home networking, with or, preferably, without wires, is already achieving much better market penetration than HDTV. MP3 devices are proliferating in all sorts of places and shapes, from the car to the basement, in a kind of "entertainment furnace." Put the two together -- networking and MP3 -- and you have wireless media streaming inside your home. If anyone questioned the transfer of power, seeing Bill Gates on stage with a professional wrestler and Intel's CEO Craig Barrett introducing an MP3 player was enough to dissipate all doubt. The Wintel CEOs are both convinced that consumer electronics are the next mother lode. But will they achieve the kind of dominance they enjoy in the PC market in this new space? The exercise is left to proud companies who've observed how Microsoft and Intel managed to siphon most of the profits from the PC makers. The years to come promise to be exciting. return to top Why I hate IAs (or the name anyway) By Tim Self, VP Business Development IA -- what does it mean? "Internet Appliance" -- a name that seems so general that it conjures up, well, not much at all. Marketeers may like the general classification because it lets analysts lump anything that uses an IP into one category and say great things about growth and future markets. But we're also ambivalent about the moniker "Internet Appliance." The name doesn't really help people understand what they are and what they do. So I thought I'd take the opportunity to muse about what IAs might actually be. Take this as my opinion and not a conclusion about what will necessarily happen. On the surface people think Internet Appliances are just cheap PC-like devices with a Web browser -- "web terminals." That's understandable, given the "Internet" portion of the name. "Appliance" means something like a household device that runs on electricity. At Be, we sometimes use the term "connected dedicated device" -- a little better, but still fairly general. Let's look further and try to nail this thing down. "Internet" refers to how the device works. It uses IP, connects to other devices, renders via standard protocols like HTML, XML, JavaScript, Macromedia Flash, and utilizes the infrastructure of the Web to do what it does. The "appliance" part is trickier. We think of it as a specialized tool devoted to a particular application. This is where IAs differentiate themselves from PCs and other general purposes boxes. Why not just have a PC? It surfs the Web, does e-mail, and is expandable if you install other applications to give it more specific functionality. Right? OK, but let's look more closely at the notion of form and functionality. IAs will manifest themselves in very different shapes, sizes, and uses than PCs. They'll be tailored for precise uses. Show me a PC that I can really hold in my lap and read like a magazine. Show me one that boots instantly like a Palm Pilot, or fits in my pocket. Show me a PC that I can haul out to my garage with faders and transport controls and record a few tracks of guitar. Or, one that operates in my stereo cabinet with the push of a remote control. The PC is just too general a piece of equipment and not built in the right form (without some major after market tweaking on my part) to work for these uses. It's also unreliable, slow, and difficult to maintain for most consumers. Don't get me wrong, I don't believe that IAs will replace PCs, but rather will augment and enhance their benefits. Right now the Palm Pilot is probably the best example of such a device. I use it away from my computer. It's great for reminding me what I have to do, looking up phone numbers, and scheduling my day. Because it easily connects to my computer (and other devices), it becomes more useful -- a prosthetic brain, if you will. I also don't expect it to do everything the computer does and it doesn't need to. Take a more mundane example in my kitchen. (My apologies to Don Norman for bastardizing his home motor reference in "The Invisible Computer" -- which you should read, as he is much more articulate than I am on such points). In my kitchen, I have a bunch of appliances that use motors. My Kitchen Aid mixer can do pretty much everything. It mixes, has an attachment for grinding, one for shredding, dicing and julienning, one for kneading bread dough, and one for blending and pureeing. While this would serve all my high-speed rotating culinary needs, I also own and regularly use a coffee grinder, a Cuisinart food processor, a blender, an eggbeater, and several Ginsu knives. Sometimes I use all of them to prepare the same meal. The point is that none of them excludes or supersedes the other. Having them serve as different manifestations of a motor (counting my arm and wrist, too) actually makes cooking faster, easier and, most important for me, more fun. Another thing I'd like to point out is that I've referred to none of these devices as "appliances," but rather by their specific or brand names. Which brings me back to the beginning. As we build an appliance we must think about exactly how it will be used and what form best fits that function. And how can we connect all the pieces to make it work as simply as my Cuisinart? Think about what a "Home Banking Terminal" might look like. Or the wireless coffee table "Couch Potato's sports pad." Or a connected home jukebox (did someone say HARP?). Or how about one of our favorites, the in-room hotel "Concierge Box." The question moves from "Would someone want this instead of computer?" to "Would someone want this to augment his/her computer with this or own this for a completely uncomputer-like use?" This is why IAs are difficult to build and have taken longer to develop than first anticipated. We have to consider hardware and form factors, user interface and client software, how they connect to the world, how hosted services and applications dovetail with these devices, and most of all, how to make this all this easy and convenient for the consumer. Internet Appliances are not just standalone devices or connections to Web sites. Though the term is broad, we must think specifically about a distinctive application and all the requirements for a particular use in order to construct a dedicated and connected appliance that delivers what's needed. Food for thought anyway.... return to top Semaphore Count Examples By Nathan Schrenk, Director of Applications You may have heard BeOS described as being "pervasively multi-threaded". When writing almost any non-trivial threaded application some form of synchronization between threads is required. The primary mechanism for thread synchronization on BeOS is a semaphore. The BeOS kernel provides functions for creating, acquiring, releasing, and deleting semaphores. The basic documentation on BeOS semaphores can be found in the Be Book in the section on semaphores. Several examples of basic semaphore usage are also included in the Be Book. One common misconception that people have regarding semaphores is that there is an inherent relationship between a specific thread and a semaphore. After a thread successfully calls the acquire_sem function, there is no ownership relationship between the thread and the semaphore. The only real result of calling acquire_sem is that the calling thread blocks until the semaphore's count is high enough that the acquire_sem operation will succeed; then the semaphore's count is decreased and the function call returns. Perhaps this concept would be more clear if acquire_sem were named decrement_sem and release_sem were named increment_sem. Because there is not any relationship between a thread and a semaphore, if a thread tries to recursively acquire the semaphore a second time, it will block. If you have need a locking mechanism that can be acquired by the same thread multiple times, you should consider the BLocker class. BLocker extends the semaphore to have an ownership relationship between the thread that acquires the lock by calling BLocker's Lock method, and the BLocker. If a thread tries to recursively lock a BLocker it will succeed because it "owns" the BLocker during the duration of the lock. More examples of the use of semaphores are described in the following sections. A Simple Read-Write Lock When protecting access to some critical data, it's often safe for many threads to read the data structure simultaneously, but not safe for a thread to read or write to the data structure at the same time as another thread writes. A read-write lock allows multiple threads to read, or one thread to write. A simple read-write lock implementation using BeOS semaphores follows. Some error checking is omitted for the sake of brevity. #define MAX_READERS 100000 class ReadWriteLock { private: sem_id fSem; public: ReadWriteLock() { fSem = create_sem(MAX_READERS, "RWLock sem"); } ~ReadWriteLock() { delete_sem(fSem); } void ReaderLock() { while (acquire_sem(fSem) == B_INTERRUPTED); } void ReaderUnlock() { release_sem(fSem); } void WriterLock() { while (acquire_sem_etc(fSem, MAX_READERS, B_ABSOLUTE_TIMEOUT, B_INFINITE_TIMEOUT) == B_INTERRUPTED); } void WriterUnlock() { while (release_sem_etc(fSem, MAX_READERS, 0); } }; As you can see by examining this class, an assumption is made that there is an upper boundary on the number of readers that can attempt to acquire the lock. This is a valid assumption in practice because there are a limited number of threads that can be created simultaneously on BeOS. The limit varies depending on system resources, and you can find out how many threads can be created system-wide with the command line tool sysinfo. Running sysinfo on my system tells me that 4096 is the maximum number of threads that can be created. Notice that a reader thread (which would call ReaderLock) decrements the count by one and then is allowed to proceed. However, the writer (which calls WriterLock) grabs the entire count. It will block until all readers have finished reading, and then once the writer holds the semaphore, no readers are allowed to proceed because the entire pool is taken. I chose the value 100,000 for MAX_READERS arbitrarily. You'll also notice that ReadWriteLock is "fair", meaning that when there is a lot of contention for the lock, the readers and writers succeed at acquiring the lock in the order in which they attempt to acquire it, which is a desirable characteristic. Enforced Output Ordering Imagine that you're writing a program to split up a large processing task so that multiple threads can work on a portion of the task, perhaps to take advantage of a four-CPU system that you have. Each thread will do some calculation, outputs the result in the form of lines of text being printed to a terminal window, and then terminate. You want the threads to calculate simultaneously, but to print out their results in a specific order. How can you use a semaphore to accomplish this synchronization? One way would be to have each thread acquire a semaphore with a count that is based the that thread's output order, print its output, and then to release the semaphore with a count that is greater than the count it acquired. To be more specific, first, a semaphore should be created with a count of 1. Let's call this semaphore outputSem. Some number of threads should be spawned to do calculation; each thread should know about outputSem and should be assigned an integer, i, that represents the order in which it should print its output with the first thread assigned an index of 1. Then each thread should perform its calculations, acquire outputSem with a count of i, print its output, and release outputSem with a count of i + 1. Can you see how this works? The first thread would acquire with a count of 1, and release with a count of 2. The second thread would acquire with a count of 2 and release with a count of 3. The third thread would acquire with a count of 3 and release with a count of 4, et cetera. No thread will print out of turn, even if the first thread finishes last, because outputSem will never have a high enough count for some thread i to acquire it if thread i - 1 has not yet released outputSem with the correct count. If you were unfamiliar with semaphores before you read this article, I hope that these two examples, in addition to the examples provided by the Be Book, have given you some ideas for using semaphores in your programs. If you have some other neat ways of using semaphores, I'm interested in hearing about them. 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!