Many areas of ACE either require or allow one to specify a time value, either for some timeout specification (such as when setting a timer to fire later) or when setting a time limit on an operation (such as timed I/O or a time-limited wait on a synchronization object). The class used to specify these time values is ACE_Time_Value. This article looks at ACE_Time_Value and the different ways it's used.

The class interface in the ACE 5.4 reference pages shows a variety of ways to initialize and set an ACE_Time_Value object. There are platform-specific data one can pass, as well as specific values for seconds, milliseconds, and microseconds. There are also methods and operators to compare ACE_Time_Value objects as well as use them in mathematical operations. What isn't clear from the interface is that an ACE_Time_Value object can represent time in two basic forms:

1. Absolute time, also known as "wall-clock" time, representing a particular point in time; e.g. June 5, 2005, 14:31:39.5
2. Relative time, or delta time, representing a period, or quantity, of time; e.g. 29.4 seconds

If ACE were being redesigned today, it would probably have different classes for absolute and relative time values. However, since there's so much ACE code in production now, it's unlikely to change. Therefore, it's very important to be sure of the correct type of ACE_Time_Value to use. The following are some cases where an absolute time is needed:

• Synchronization class wrappers, such as ACE_Thread_Mutex and ACE_Condition_Thread_Mutex
• ACE_Task methods, such as waiting for a task's completion
• ACE_Message_Queue methods; these methods usually pass the time value through to a synchronization object
• ACE timer queue scheduling methods (not via ACE_Reactor, but when using a separate timer queue)

Compare these with some times that a relative time value is called for:

• ACE_Reactor and ACE_Proactor event loop limits and timer scheduling methods
• ACE IPC wrapper facade (such as ACE_SOCK_Stream) I/O methods
• ACE_Process, ACE_Process_Manager, and ACE_Thread_Manager wait() methods
• Time slice quantum for the ACE_Sched_Params class

Notice that, in general, relative times are often used where the operation may delay before being able to proceed, but will be called only once. Conversely, absolute time values are often used where the operation may be called multiple times via a loop, such as waiting on a condition variable. Use of an absolute time avoids the need to recompute the timeout value for each loop iteration.

The easiest way to set a absolute time is to use the ACE_OS::gettimeofday() method to return the current absolute time in an ACE_Time_Value form. Once the current time is available, it's possible to add some time period to it. For example:

   ACE_Time_Value now = ACE_OS::gettimeofday();
   now += 5;         // 5 seconds from now

The ACE development community is hard at work on the next version of ACE. Here are some of the things you can look forward to (items in bold are new or changed since last month):

• Native library path-searching. Previous ACE versions's implementation of ACE_DLL (used in loading dynamic services) implemented a search of the configured path-search to try and locate the desired library file (DLL) and then used the full pathname to load the library. This skirted some platforms's rules for path search and security settings. This has been changed in the next ACE version to make use of all of the native platform's path-search and security facilities.
• Improved wide-character support. Wide- character support has been included in ACE for many years on Windows (also known as Unicode builds). However, wide-character support for POSIX platforms has been sorely lacking. As ACE's reach expands, this has become a more important issue. Riverace is leading the completion of wide-character support in the next version of ACE. This support is also available now in the ACE 5.4b fix kit.
• GNU autotools support. Riverace is the lead developer in charge of adding auto-configure support to ACE. For native-build, non-Windows systems, autoconf will very likely become the way to configure and build ACE. This will help insure that ACE uses the latest features available on each supported platform, and reduce the work required to build ACE. No more picking the right config.h or platform_macros.GNU file. Just do ./configure then make. Ahhh...
• Support for g++ 4.0, 3.4 and Microsoft Visual C++ 2005 are being added.
• Support for Red Hat Enterprise Linux 4.
• Newer C++ Features Being Used. As the range of ACE-supported compilers matures and older compilers are taken out of service, ACE can make more use of newer C++ features while still maintaining its stellar portability record. For example, many methods that returned 1 or 0 as an int now return bool. Small steps, yes, but significant ones. You'll see more modern C++ usage as time goes on.
• The ACE and ACE_OS classes, previously containing a number of static member functions, are now C++ namespaces. Similar ACE-internal classes, such as ACE_Sock_Connect, are no longer in use.

As you can see, the pace of changes is slowing and the ACE development team is beginning to focus more on testing in preparation for the release of ACE 5.5. The current estimate for ACE 5.5's release is late in 2005, so there's time to get a bit more in. In particular, the ACE_Dev_Poll_Reactor implementation for Linux would be a great addition. This was mentioned in our March 2005 newsletter - please check it out using the link below for more information!

If you're planning a new project to start soon, or find yourself grappling with how to apply ACE to your current project, remember that Riverace provides world-class development and consulting services with special expertise in ACE. We can help you be sure that your new system is designed to take full advantage of ACE's power and flexibility, getting your system delivered in the shortest possible time and with the highest level of quality. Please contact Steve Huston at 888-384-8154 (toll-free in the US) or +1 508- 541-9180 to discuss how Riverace can help you.