ACE Tutorial 018
The FIFO Nature of ACE_Token


Welcome to Tutorial 18!

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:


[Tutorial Index] [Continue This Tutorial]