Take the 2-minute tour ×

Simple question, I think.

I have one thread that responds to a callback that is called when a user connects via TCP. That callback wants an answer if I accept or reject the login. Problem is I have to send a login request to a security server via asynchronous message passing and wait for a response.

What is the best way to handle this? Right now I have some code that just loops in the callback testing to see if the security server has sent a reply and when it comes in I read it and return the appropriate boolean. It just seems kind of gross.


share|improve this question
Like I'm thinking maybe a Boost condition_variable or some such thing. –  shaz Jul 26 '10 at 22:16
I've noticed a number of questions almost identical to this recently. Is this a class project of some sort? Just curious. –  Amardeep Jul 30 '10 at 12:14

3 Answers 3

First of all, you need a locking library that contains a monitor class with the ability to:

  • acquire a lock, guaranteeing mutual exclusion, i.e. that only one thread can hold the lock at any time
  • sleep on the lock, which means releasing the lock temporarily, and sleeping until the lock can be reacquired
  • signal on the lock, notifying sleeping threads that they should wake up and reacquire the lock. It is only possible to signal on the lock while holding the lock. This means that the signal will never have the immediate effect of waking up other threads. Typically the signaling thread will signal and then immediately release the lock, allowing the threads that have just been signaled to wake up. Waking up has the effect of a return of the blocking call to sleep, with the lock reacquired.

So with that functionality available from some library, you need to implement a security server proxy that uses the asynchronous security server to implement a synchronous service. When the synchronous authenticate() function is called in some thread (denoted thread 1), this is what should happen:

  1. proxy acquires the lock
  2. proxy sends a request message to the security server
  3. proxy goes to sleep, waiting for the result, thread 1 is now blocked and the lock is available
  4. security server computes a result
  5. security server sends a message with the result to the proxy
  6. the proxy message handler function is called in thread 2, thread 1 is still blocked
  7. the proxy acquires the lock in thread 2
  8. the proxy retrieves the result from the message and stores it in a member variable
  9. the proxy signals on the lock, causing thread 1 blocking on sleep to try to wake up, but it can't, because thread 2 still holds the lock (inside the sleep() function, thread 2 is now blocked on a call to acquire the lock)
  10. the proxy message handler releases its lock
  11. the sleep call in thread 1 reacquires the lock and returns
  12. the synchronous function in thread 1 then immediately releases its lock and returns the result

The last part with thread 1 reacquiring the lock only to immediately release it may seem pointless, but it matters because this ensures that the message handler is done before the synchronous function proceeds.

In pseudocode, it actually looks a lot simpler that you might expect:

class SecutityProxy
    SecutityProxy( SecurityServer& server ) : m_server(server)
    Result authenticate( username, password )
        m_server.send_message( username, password );
        return m_result;
    void message_received( message )
        m_result = message;
    SecurityServer& m_server;
    Monitor m_monitor;
    Result m_result;

Note that this implementation cannot handle more than one request at a time! In order to handle multiple concurrent requests, you need to be able to store multiple results. You also need to store the thread handles of the threads that correspond to each request. In the message handler, you need to figure out which thread is blocking on any given request, and then just wake up the relevant thread in the signal() call, the locking library must support this.

Note also that it is highly recommended to implement a RAII class to handle the lock() and unlock() calls on the monitor.

share|improve this answer

Presumably, you would block on your asynchronous call to the security server to effectively make it synchronous.

share|improve this answer
Yeah, but block how, use a mutex, sleep and check a variable? The call to the SecSrv is asynch so once I call, it returns immediately and I have to do something explicit to block and wait for the return message. I'm really asking almost a style question I suppose, what's the smoothest way to code this? –  shaz Jul 26 '10 at 21:43
I can't block in the asynchronous call, I send a message and receive a message back in a different thread some time later. –  shaz Jul 27 '10 at 17:03
I was looking at the sample code here (windows-tech.info/13/e64a22df23c19164.php) and I didn't see any particular reason why your callback can't block on an Manual Reset Event before returning. –  Steven Sudit Jul 27 '10 at 18:28

In the function that initiates the login check, after sending the message to request the check block on something. A Windows Event would work, as would a boolean flag and a boost::condition_variable or a boost::unique_future.

In the code that receives the response message from the security server set the event, or future or flag/condition variable. This will then wake up the initial function and allow it to return the appropriate response to the initial caller.

share|improve this answer

Your Answer


