We've seen various ACE methods for synchronization in this and other tutorial sections. Something we haven't yet seen is the ACE_Token. ACE_Token has a really cool thing: it behaves in a FIFO manner.

Why is that cool?

In the other tutorials, you may have found that one thread will end up with all of the work. Even though other threads are available, the OS scheduling and lock management just causes it to happen. With ACE_Token, the threads are queued up on the token and served in a traditional first-in-first-out manner.

Why is FIFO important?

Well, if your app is running in a bunch of threads and each is doing the same thing on the local host then FIFO may not be important. However, take the case where each thread is connected to a remote system. Let's say you have a dozen threads in your app and each is connected to a different remote system. Each of the threads will be given a block of data which will be passed to the remote for some intense calculation. If you use the FIFO then you'll spread the work more-or-less evenly between the remote peers. If you use the traditional mutex then one peer may get the lion's share of the work.

It gets down to a personal decision based on the application's needs. Consider your application, examine its behavior & decide for yourself if you want to spread the work evenly or if it's OK to let some threads work harder than others.

Kirthika's abstract:

A token is similar to a mutex-lock, with the difference being that the token is given to the waiting threads in a FIFO order. In the case of the mutex-lock, any thread (depending on the OS) could acquire the lock when its released. It internally implements a recursive mutex, i.e. the thread that owns the mutex can reqacquire it without deadlocking. The token also has two FIFO lists for writers and readers with writer- acquires having a higher priority than reader-acquires.

This tutorial throws light on the differences on having a shared resource governed by a lock and a token, both derive from a Task which simply updates a counter with the number-of-threads value. A barrier is used for ensuring that all threads get a equal opportunity of grabbing the token. The message queue with the message containing the thread count moves among the threads to be obtained and read.

On obtaining the results, we conclude that on using the Token, the job to be completed can be distributed evenly among available threads. This cant be guaranteed in case of simply using the lock for synchronisation.