Re: [Quickfix-developers] Thread safety question
Brought to you by:
orenmnero
From: <or...@qu...> - 2008-05-13 21:04:46
|
Not a problem. QuickFIX protects the session with a mutex so you can call sendToTarget without worry from any thread. --oren > -------- Original Message -------- > Subject: [Quickfix-developers] Thread safety question > From: John Haldi <jr...@ya...> > Date: Tue, May 13, 2008 1:34 pm > To: qui...@li... > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html<hr>I was wondering if anybody might be able to answer the following: > I'm creating a client trading application which takes advantage of the ThreadedSocketInitiator to make a connection to an exchange. (I do not currently use the SynchrozinedApplication, if that makes a difference to my question.) In my trading application, I want to be able to react to an ExecutionReport of type Fill or Partial fill in a particular ETF by responding with a hedge that is comprised of a collection of NewOrderSingle messages. In other words, I want to send out a basket of orders each time I get a fill. > In the simplest scenario, I might get a fill for a particular ETF and want to send out 10 buy orders (ten NewOrderSingle messages, one for each different stock in the basket). So far this application tests without a problem. To send the basket of orders, I'm grabbing a thread from the threadpool (.NET application, fyi), and generating my orders on that thread and calling SendToTarget for each order I create. After creating and sending the basket, the thread is returned to the thread pool. In this manner, I allow my trading client to return from the "CreateBasketOrders" call on the primary thread while the basket itself is created and sent out. > Here's the part I'm concerned with though. Imagine a very common scenario in which an order to buy 5,000 shares of a particular ETF comes back in a handful of partial fills in very fast succession (say, for example, 100 share fills, each 2-3 ms apart). Now imagine that my thread that generates the basket takes 50 ms to actually complete (imagine that I'm sending a basket on the S&P 500, so my basket has 500 NewOrderSingles to create and send). > If I get 10 fills in rapid fire succession, I will create 10 concurrent threads (from the threadpool) which are each creating some #n of NewOrderSingles and each calling SendToTarget concurrently. Will quickfix handle the calls to SendToTarget from multiple threads gracefully, or do I have to manage some sort of locking mechanism to ensure that SendToTarget can't be called concurrently by different threads at the same time? If QF can handle this internally, great. If not, would it work to create a wrapper function in my app (called perhaps "ThreadSafeSendToTarget") which wraps the SendToTarget method with a ReaderWriterLock object and prevents concurrent calls? > Any advice would be greatly appreciated. > Many thanks, > John<hr>------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/<hr>_______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers |