Dr. Dobb's Journal - January 2008 - (Page 69) d02sutt_p5ma 11/9/07 11:42 AM Page 69 Effective Concurrency diagnostic dump that you can review later if a problem does occur. A Word About Composability Although lock hierarchies address many of the flaws of locks, including the possibility of deadlock, they still share the same Achilles Heel: Like locks themselves, lock hierarchies are not in general composable without some extra discipline and effort. After all, just because you use a lock hierarchy discipline correctly within the code you control, a separately authored module or plug-in that you link with won’t necessarily know anything about your lock hierarchy unless you somehow inform them about your layers and how they should fit into the hierarchy. For example, look at the sample application architecture in Figure 1 again, and consider: What if the application wants to allow plugins that are called from the 5000s layer? First, of course, the program and all the plug-ins should make every effort to avoid calling unknown code (in this case, each other) while holding a lock. But, as we saw last month (“Avoid Calling Unknown Code While Inside a Critical Section” DDJ, , December 2007), we can encounter trouble even if a plug-in takes no locks of its own but may call back into the main program and create a code path that unexpectedly calls up into higher level code that takes a higher level lock. So the plug-ins must be aware of the layering of the application and be told that they are to operate at (say) level 4999, and may only call APIs below level 4999. to operate at, and therefore the API calls they can and can’t make (those below their level and those at or above their level, respectively). Next month, we’ll start to look into issues and techniques for writing scalable manycore applications. Stay tuned. Notes [1] Or otherwise gets the same effect. For example, it is possible to just start trying to acquire the locks in some randomly selected order using try_lock operations, and if we can’t acquire them all just back-off (unlock the ones already acquired) and try a different order until we find one that works. Surprisingly, this can be more efficient than taking the locks in a hard-coded global order, although any backoff-and-retry strategy has to take care that it doesn’t end up prone to livelock problems instead. But we can leave all this to the implementer; the key is that the programmer simply writes lock( /* whatever */ ) and is insulated from the details of determining the best way to keep the order consistent. DDJ Herb is a software architect at Microsoft and chair of the ISO C++ Standards committee. He can be contacted at www.gotw.ca. HD PHOTO N O W A V A I LA B LE F O R D O W N L O A D I S 4 0 - 6 0 % F A ST E R I N P I C TO O LS . Summary Keep it on the level: Use lock hierarchies to avoid deadlock in the code you control. Assign each shared resource a level that corresponds to its architectural layer in your application, and follow the two rules: While holding a resource at a higher level, acquire only resources at lower levels; and acquire multiple resources at the same level all at once. If your program will call external code, especially plug-ins, then document your public API sufficiently for plug-in authors to see what level their plug-in is expected Speed-optimized HD Photo libraries are now available within the PICTools Software Development Kit (SDK). Microsoft’s HD Photo offers higher image quality, greater preservation of data and advanced features for today’s digital imaging applications. It is a still image compression algorithm for continuous tone photographic images and features lossy, as well as lossless, compression, multiple colorspaces, a wide dynamic range, and extensive metadata support. PICTools SDKs contain low-level C libraries offering advanced image compression, decompression, and editing. Maximum code speed has been achieved through algorithm and machine code optimizations. Also available for .NET and ActiveX. Supported across: 32-bit Sun Solaris 32-bit and 64-bit Linux 32-bit and 64-bit Microsoft Windows IBM AIX Mac OS X Contact us for more information. W W W . P E G A S U S I M A G I N G . C O M Pegasus is a registered trademark of Pegasus Imaging Corporation in the United States. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. January 2008 l www.ddj.com l Dr. Dobb’s Journal 69 http://www.gotw.ca http://www.pegasusimaging.com http://www.pegasusimaging.com http://www.pegasusimaging.com http://www.ddj.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.