10.1 Overview

I l @ ve RuBoard

Hardware characteristics can affect the behavior of OS threading mechanisms significantly. For example, multiple threads can run in parallel on separate processors. On a uniprocessor , only one thread is active at any point in time, though threads may be scheduled in and out of execution, giving the appearance of running in parallel. In both of these scenarios, however, developers must use synchronization mechanisms to avoid race conditions and to ensure that their applications coordinate their access to shared resources.

Different operating systems provide different synchronization mechanisms with different semantics using different APIs. Some of these APIs conform to international standards, such as Pthreads [IEE96]. Other APIs conform to de facto standards, such as Win32 [Sol98]. This chapter describes the following ACE classes that networked applications can use to synchronize threads and/or processes portably:

ACE Class Description
 ACE_Guard ACE_Read_Guard ACE_Write_Guard 
Apply the Scoped Locking idiom [SSRB00] to ensure a lock is acquired and released automatically when a block of C++ code is entered and exited, respectively.
 ACE_Thread_Mutex ACE_Process_Mutex ACE_Null_Mutex 
Provide a simple and efficient mechanism that concurrent applications can use to serialize access to shared resources.
 ACE_RW_Thread_Mutex ACE_RW_Process_Mutex 
Allow efficient, concurrent access to re-sources whose contents are searched much more often than they are changed.
 ACE_Thread_Semaphore ACE_Process_Semaphore ACE_ Null Semaphore 
Implement a counting semaphore, which is a general mechanism for synchronizing multiple threads of control.
 ACE_Condition_Thread_Mutex ACE_Null_Condition 
Allow threads to coordinate and schedule their processing efficiently .

These wrapper facades provide the following benefits:

  • Improve type safety by

    - Automating the initialization of synchronization objects, for example, when they appear as data members in C++ classes.

    - Preventing incorrect usage, for example, copying one mutex to another.

    - Ensuring that locks are acquired and released automatically as scopes are entered and exited, even if exceptions or errors occur.

  • Ensure portability across heterogeneous OS platforms. For example, ACE provides portable implementations of readers/writer locks and condition variables on platforms that don't support these synchronization mechanisms natively.

  • Enhance abstraction and modularity without compromising efficiency. Using C++ language features, such as inline functions and templates, ensures that the ACE synchronization wrapper facades incur little or no additional time and space overhead.

  • Export a uniform synchronization interface that enables applications to acquire and release various types of locks. For example, the ACE mutex, readers/writer, semaphore, and file lock mechanisms all support the ACE_LOCK* interface shown in Figure 10.1. ACE_LOCK* is a "pseudo-class," that is, it's not a real C++ class in ACE. We just use it to illustrate the uniformity of the signatures supported by many of the ACE synchronization classes, such as ACE_Thread_Mutex , ACE_Process_Mutex , and ACE_Thread_Semaphore .

    Figure 10.1. The ACE_LOCK* Pseudo-class

  • Reduce the amount of obtrusive changes needed to make code thread-safe. The uniformity of the ACE synchronization interfaces enables a single ACE_Guard template class to ensure that most types of locks can be acquired and released as scopes are entered and exited, respectively.

This chapter motivates and describes the capabilities of the core ACE synchronization wrapper facade classes. We present examples of each class to illustrate how they can simplify common synchronization issues encountered by concurrent networked applications.

I l @ ve RuBoard


C++ Network Programming
C++ Network Programming, Volume I: Mastering Complexity with ACE and Patterns
ISBN: 0201604647
EAN: 2147483647
Year: 2001
Pages: 101

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net