Used as a synchronization mechanism to coordinate concurrent access to an ACE_Reactor_Impl object. More...

#include <Reactor_Token_T.h>

Inheritance diagram for ACE_Reactor_Token_T< ACE_TOKEN_TYPE >:

Collaboration diagram for ACE_Reactor_Token_T< ACE_TOKEN_TYPE >:

Public Member Functions
	ACE_Reactor_Token_T (ACE_Reactor_Impl &r, int s_queue=ACE_TOKEN_TYPE::FIFO)

	ACE_Reactor_Token_T (int s_queue=ACE_TOKEN_TYPE::FIFO)

virtual	~ACE_Reactor_Token_T (void)

virtual void	sleep_hook (void)

ACE_Reactor_Impl &	reactor (void)
	Get the reactor implementation. More...

void	reactor (ACE_Reactor_Impl &)
	Set the reactor implementation. More...

virtual void	dump (void) const
	Dump the state of an object. More...

Public Attributes
	ACE_ALLOC_HOOK_DECLARE
	Declare the dynamic allocation hooks. More...

Private Attributes
ACE_Reactor_Impl *	reactor_

Detailed Description

template<class ACE_TOKEN_TYPE>
class ACE_Reactor_Token_T< ACE_TOKEN_TYPE >

Used as a synchronization mechanism to coordinate concurrent access to an ACE_Reactor_Impl object.

For ACE internal use only.

This class is used to make access to a reactor's internals and demultiplexing mechanism thread-safe. By default, the thread that runs the handle_events() loop holds the token, even when it is blocked in the demultiplexer. Whenever another thread wants to access the reactor, such as via the register_handler(), remove_handler(), etc. methods, it must ask the token owner for temporary release of the token. To accomplish this, this class reimplements the ACE_Token::sleep_hook() method through which the owning thread can be notified to temporarily release the token if the current situation permits.

The owner of the token is responsible for deciding which request for the token can be granted. By using the ACE_Token::renew() method, the thread that releases the token temporarily can specify to get the token back right after the other thread has completed using the token. Thus, there is a dedicated thread that owns the token by default. This thread grants other threads access to the token by ensuring that whenever somebody else has finished using the token the original owner reclaims the token again, i.e., the owner has the chance to schedule other threads. The thread that most likely needs the token most of the time is the thread running the dispatch loop.