[ 0019 ] fig1 shows a computer system 100 constructed in accordance with the preferred embodiment . computer system 100 generally comprises a microprocessor or cpu 20 coupled to a main memory 26 and various other peripheral computer system components , through an integrated host bridge 22 . the cpu 20 preferably couples to the host bridge 22 via a host bus 24 , or the host bridge logic 22 may be integrated into the cpu 20 . the cpu 20 preferably comprises an itanium ™ microprocessor manufactured by intel corporation . it should be understood , however , that computer system 100 could comprise other types and brands of microprocessors as well . for example , computer system 100 may comprise a pentium iii ™ or pentium iv ™ microprocessor , or any microprocessor later developed , by intel corporation . the cpu 100 may also comprise any microprocessor made by advanced micro devices . thus , the computer system may implement other bus configurations or bus bridges in addition to , or in place of , those shown in fig1 . moreover , computer system 100 could also comprise several microprocessors , as may be used in applications such as a server system . main memory 26 preferably couples to the host bridge 22 through a memory bus 28 . the host bridge 22 preferably comprises a memory control unit ( not shown ) that controls transactions to the main memory 26 by asserting the necessary control signals during memory accesses . the main memory 26 functions as the working memory for the cpu 20 and generally comprises a conventional memory device or array of memory devices in which programs , instructions and data are stored . the main memory 26 may comprise any suitable type of memory such as dynamic random access memory ( dram ) or any of the various types of dram devices such as synchronous dram ( sdram ), extended data output dram ( edo dram ), or rambus ™ dram ( rdram ). the computer system 100 also preferably comprises a graphics controller or video driver card 30 that couples to the host bridge 22 via an advanced graphics port (“ agp ”) bus 32 , or other suitable type of bus . alternatively , the video driver card may couple to the primary expansion bus 34 or one of the secondary expansion buses , for example , pci bus 40 . graphics controller 30 further couples to a display device 32 which may comprise any suitable electronic display device upon which any image or text can be represented . the computer system 100 also preferably comprises a second bridge logic device 36 that bridges the primary expansion bus 34 to various secondary buses such as a low pin count ( lpc ) bus 38 and a peripheral component interconnect (“ pci ”) bus 40 . in accordance with the preferred embodiment the bridge device 36 comprises an input / output controller hub (“ ich ”) manufactured by intel corporation . although the ich is shown in fig1 only to support the lpc bus 38 and pci bus 40 , various other secondary buses may be supported by the ich 36 . in the preferred embodiment shown in fig1 the primary expansion bus 34 comprises a hub - link bus which is a proprietary bus of intel corporation . however , computer system 100 is not limited to any particular type of chipset and thus the primary expansion bus may comprise any other suitable buses . referring still to fig1 a firmware hub 42 couples to the ich 36 by way of the lpc bus 38 . the firmware hub 46 preferably comprises read only memory ( rom ) which contains software programs executable by the cpu 20 . the software programs preferably comprise not only programs to implement basic input / output system ( bios ) commands , but also include instructions executed during and just after power on self test ( post ) procedures . these software programs perform various functions including verifying proper operation of various system components before control of the system is turned over to the operating system . in broad terms , the preferred embodiments of the present invention are directed to synchronizing access by software streams to bios routines . the preferred embodiments were developed in the context of software streams accessing shared variables through the use of bios routines , and thus the following description is related to the context of development ; however , the description in this manner should not be construed as a limitation as to the scope of applicability of the concepts described . [ 0026 ] fig2 shows a flow diagram which exemplifies the preferred procedure for a software thread or stream calling bios routines . in particular , the process starts at step 50 and proceeds directly to the step of opening the bios group ( step 52 ). for some bios routines in a computer system , no synchronization is required , and thus these bios routines need not be opened and closed as described in the preferred embodiments . while it would be possible to require software streams to open and close the entire bios before executing any bios routines , preferably only certain groups of routines , those groups that manage access to shared variables , are opened and closed as described in the preferred embodiment . moreover , opening a bios group should not necessarily be construed to mean that more than one bios routine should be grouped for opening and closing purposes . it is possible that even a single bios routine , where that bios routine requires synchronization between multiple software streams , may comprise a bios group . thus , in step 52 , the calling software program attempts to open the bios group . preferably , the next step in the procedure is to examine the return value from the open procedure ( step 52 ). more particularly , if the return value is a valid handle ( step 54 ), then the process continues to step 56 where the calling software stream , now holding the valid handle , is allowed to call bios routines to perform the desired operation on the shared variables . if , however , the return value from step 52 is not a valid handle , indicating that the bios is already opened and owned by another software stream , then preferably the calling software stream pauses momentarily ( step 58 ) and again attempts to open the bios group ( step 52 ). once the software stream has completed its desired task with respect to the shared variables , the software stream preferably closes the bios group ( step 58 ) effectively returning the open handle , and the process ends ( step 60 ). consider for purposes of explanation a first software stream and a second software stream , the software streams either executed on the same microprocessor or on different microprocessors . further consider that both software streams need to access and / or update shared variables maintained through the use of bios routines . still referring to fig2 consider that the first stream is the first to attempt to open the particular bios group of interest . in such a case , the first software stream moves through steps 50 , 52 , 54 and 56 of fig2 . consider also that the second software stream is the second to attempt to access the bios routines . in this case , the second software stream progresses through steps 50 , 52 and 54 of fig2 but because the particular bios group is already open and owned by the first software stream , the return value from the attempt to open the bios group is not a valid handle . thus , the second software stream begins a process of circularly attempting to open the bios group ( step 52 ), examining the return value for indications of a proper handle ( step 54 ), pausing ( step 58 ), and attempting again to open the bios group ( again step 52 ). once the first software stream completes the necessary operations with regard to the shared variables , the first software stream closes the bios group and returns the handle ( step 58 ), and the process with regard to the first software stream ends ( step 60 ). however , once the first software stream returns the handle , the handle again becomes available for allocation . as soon as the handle becomes available and the second software stream enters the open bios group step ( step 52 ), the second software stream is passed a valid handle and the second software stream may perform its desired updating of the shared variables . in the exemplary case of two software streams attempting to update the same shared variable , synchronization is provided by the preferred opening , owning and closing the particular bios group that performs the desired function . in such a circumstance , there is no need to artificially inflate the execution priority of either the first or second software streams , nor is there a need for either stream to ascertain and utilize a designated driver program to obtain access to the bios routines . [ 0031 ] fig3 shows a flow diagram of the open request process on the receiving end . in particular , the process preferably starts at step 62 , and the first step thereafter is the receipt of an open request by a software stream ( step 64 ). after receipt of the open request , a decision is made regarding whether the particular bios group is already opened ( step 66 ). if the bios group has not been previously opened , then the return value is set to be a valid handle , and the process ends ( step 68 ) ( returning a valid handle ). if , however , the bios group has already been opened , then the return value is set to an invalid handle , and the process ends ( step 68 ). although the steps described above may be implemented in any computer system , in the preferred embodiment , the steps are implemented in a system having at least one itanium ™ microprocessor made by intel corporation . as one of ordinary skill in the art is aware , in systems operating with an itanium ™ microprocessor and related chipset , bios routine calls are made to a system abstraction layer ( sal ). for more information regarding the itanium ™ processor family system extraction layer , reference may be had to intel document no . 245359 - 003 titled “ itanium ™ processor family system abstraction layer specification ,” dated january 2001 , incorporated herein by reference as if reproduced in full below . thus , rather than the traditional loading of a services number into a register of the microprocessor and issuing a software interrupt , in the itanium ™ system kernel mode software preferably communicates in a c language format function call with the system abstraction layer to request bios type services . while certain bios routines are generic to every computer system , oems have the ability to specify and use custom bios routines . thus , additional routines may be added to the system abstraction layer of the itanium ™ processor family . in the preferred embodiments , implementing the open , use and close technique for routines that modify shared variables preferably takes place at the sal level of the computer in a c language format function call . however , the same procedures and steps may be implemented directly at the bios routine level without departing from the scope and spirit of this invention . the above discussion is meant to be illustrative of the principles and various embodiments of the present invention . numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated . for example , the embodiments above are described in the context of an open , use , close system ; however , any system in which one or more bios routines ( even if implemented through a system abstraction layer as in an itanium ™ system ) are assigned to a software stream to the exclusion of other streams for synchronization purposes would be within the contemplation of this invention . this specification describes only the preferred implementation of accomplishing the task . one of ordinary skill in the art , now understanding the concept described , could design equivalent systems . it is intended that the following claims be interpreted to embrace all such variations and modifications .