APG Section 14.2.2 contains a description of barriers and how to use the ACE implementation of barriers, ACE_Barrier. Barriers are often used when a group of threads must all proceed to some predefined waiting point before they all continue. For example, if a group of related threads must all complete some initialization before proceeding, a barrier could be used after the initialization code. As each thread reaches the barrier, it blocks to wait for the others. When all threads have reached the barrier, they all continue at once.

What happens, though, if a thread in the group encounters some fatal error that would cause the thread to not wait, or a situation where the threads that already waited (or are about to wait) should be told to abort and take alternative action, such as exiting? Up to this point, the only operation on the ACE_Barrier class is wait(). This meant that abort situations required some clever programming on the part of the user to properly release all the waiting threads and signal that something is wrong. This problem has now been remedied.

A long-time ACE user, John Lilley, at DataLever encountered a situation where one thread of a group may need to abort a barrier. Necessity being the mother of invention, John invented the requisite new method ACE_Barrier::shutdown(). When a thread calls ACE_Barrier::shutdown(), all threads waiting at the barrier are released immediately and any threads that call ACE_Barrier::wait() after the shutdown also will immediately fail. After a shutdown, the return value from wait() is -1 and errno is set to ESHUTDOWN instead of the normal return value of 0. The ACE_wrappers/tests/Barrier_Test.cpp program (part of ACE's regression test suite) was extended to test this behavior and also serves as an illustration of its use.

Thanks to John's and DataLever's generosity, all ACE users will enjoy this new feature in ACE version 5.5 (for an early look at it, it's in the ACE 5.4.9 beta, coming in a few days). If you have new features for ACE, contact Steve Huston at Riverace to see about getting them included in ACE!

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 and 3.4.
• Support for Red Hat Enterprise Linux 4.
• Support for Solaris 10.
• Support for Microsoft Visual Studio 2005 on desktop, Pocket PC 2003, and Windows Mobile 5.0.
• Support for IBM AIX 5.3 on POWER with IBM's C++ V7.
• Support for HP-UX 11iv2 on both Itanium2 and PA-RISC.
• 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.
• Completed ACE_Dev_Poll_Reactor. Sharpcast is sponsoring Riverace's work to complete this important class, enabling use of the new epoll facility on newer Linux kernels. Thanks to Sharpcast's forward-thinking investment in this important class, the entire ACE user community will benefit from the greatly increased scalability of the Reactor framework on Linux.

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 1Q2006, so there's time to get a bit more in.

The ACE 5.4e Fix Kit was recently released. The 5.4 fix kit ChangeLog contains entries for all changes made.