Desktop API in multi-thread environment

[yuriy_zubarev]

Greetings,

I was wondering if Desktop API was written in consideration of being used in multi-thread applications.

What I have is multiple threads downloading historical data for different symbols and a thread that calls get_RequestHistory isn't always the one where OnBarsReceived is triggered. After I run my app, MSFT has data for SUNW and other nonsense.

Any ideas?

[DionLoy]

Generally APIs leave multithreaded safety up to the applications that use them for efficiency purposes (as applications can make better assumptions based on their usage, as well as not slowing down single threaded applications who have no need for it). eg, Java Swing, MFC, boost++ libraries, STL, etc ...

Also, eSignal itself is single threaded wrt to data processing so this is unlikely to change.

That being said, you shouldn't be receiving SUNW data for MSFT requests. Are you matching up the symbol according to the bar request handle that you get back from calling get_RequestHistory() ?

could you post the snippets of code that you use for requesting history and for doing the OnBarsReceived processing?

thanks!

[yuriy_zubarev]

Thank you for your reply.

I started matching request handlers and ran into another "problem". When OnBarsReceived method is triggered I check that Handle that gets passed as a parameter equals Handle that is set for this thread (object). When those two valus are equal everything is OK, but when they are not, the event is already consumed and is not going to be fired again for a correct thread to capture it...

[yuriy_zubarev]

Well I made it to work in a singleton manner with static methods and synchronized access which made it possible to use in a multi-thread environment... But guess what, with all this synchronization dance all benefits of multi-threading are negated...

I don't want to be a party pooper but I'm quite dissapointed with Desktop API. If eSignal core engine is running on only one thread (as pathetic as it may be) then you probably could not do anything. But if the engine can handle multiple request/response calls at the same time then come on! The API would need a major make-over.

Regards.

[GenSpoo]

IMHO, data reception should only occur in one thread anyway. Having a separate thread for each symbol is overkill, and if you think about the fact that the incoming data is serialized through your single network connection anyway so even on a true multi-CPU system, having multiple incoming data threads isn't of great value. And context switches are not free. So just one thread listening for data that then puts the data in a structure for use by the data processing threads is the way I do it. Works just fine.

I suppose I could see the desire for one thread per symbol if you were doing processing on the data as it arrives as opposed to storing it and then doing the processing. Just seems a bit heavy, especially if you watch more than a few symbols.

Cheers... George

[yuriy_zubarev]

I would disagree. API should not restrict me severely in the way I need to utilize it. Whether I need 100 threads or just 1 it's up to me and requirements of the particular application.

Multi-threading doesn't mean 1 thread per 1 symbol. I may as well use 1 thread to request 10 symbols (sequentially within one thread) and then for 100 symbols I would only create 10 threads. Performance benefit is quite significant.

The problem with Desktop API is that an instance of IESignal.Hooks is a global static instance and I cannot create as many instances as I need thus limiting me to use eSignal Desktop API as a non-thread-safe.

Regards.

[GenSpoo]

I really wasn't making a comment on the current API functionality one way or the other. I was just speaking in general on threading and that I don't think threading the way you would like the API to be threaded would add any performance benefits (over a system designed to work with the current system in the best manor it can be utilized right now).

I agree that using threading to process (e.g. technical analysis) the data can have huge performance benefits on machines with multiple CPUs (or even just hyperthreading). But I don't think using more than one thread for the data retrieval will gain you anything in terms of performance.

Again I'm not really talking about the API, just ways to utilize threads for performance. If you are doing the processing (other than just storing) of the incoming data in those threads, I see a benefit. That isn't the way I would do it though. With a incoming stream of data, just like with interrupt handlers or blocking kernel calls, my philosophy is get out as fast as possible. Leave the processing for elsewhere when you can. Just the way I look at it.

Cheers... George

[yuriy_zubarev]

OK, I will provide metrics to back up my point and shake your theory on multi-threading for data downloading.

Task: download 6 month worth of data for all NASDAQ 100 symbols (daily time frame).

Implementation 1: using HTTP interface to Yahoo Finance.

1 thread - 53 sec
2 threads - 21 sec
3 threads - 15 sec
4 threads - 11 sec

This implementation uses classes from System.Net package that are all thread-safe and therefore multi-threading can be utilized to the fullest.

Implementation 2: using eSignal Desktop API

1 thread - 129 sec
2 threads - 74 sec
3 threads - 60 sec
4 threads - 60 sec (not a typo)

Since Desktop API is not thread-safe I had to resort to different locking mechanisms and it showed. In the first case performance increased 4.8 times from 1 to 4 threads; in the second case - 2.15 times.

I hope this demonstrate clearly why I'm not quite happy with Desktop API. And yes, multi-threading does help while downloading data.

Regards.

[GenSpoo]

The reason, I am guessing, that you got such a speed up with Yahoo is that filling the number of requests asyncronously and thus with more threads was better utilizing the bandwidth of your Internet connection (or their server, or whatever the limiting factor was). With a web server that only allows you to ask one thing per request and then you have to wait for the results before asking for another request, there would be a performance gain (until you hit the max bandwidth of your connection, after which you would gain nothing with more threads) since it treats multiple simultaneous requests as multiple users and sends them at the same time filling up the bandwidth. I agree that multithreads help here, but this is not an apples to apples comparison really.

Now if a data server were to allow you to make multiple requests without needing to wait for the first to complete as eSignal does (as opposed to the way the web server does), then it could fill up the bandwidth just the same as the web server instance above, only it wouldn't need lots of threads pretending to be lots of different users. It would work by interleaving the data through a single connection. Thus you wouldn't need multiple threads and multiple threads would gain you nothing in terms of performance. This might be why adding more threads to your eSignal version of your app stopped producing performance gains.

But then, I am speculating and I have never seen your code or eSignals, and haven't done any concrete testing of this on my own. So I'll leave those as my final thoughts on the matter. They could be wrong, or they could be right.

Cheers... George

[DionLoy]

GenSpoo is correct. Your HTTP connections to Yahoo can be run in parallel. In eSignal there is only one data channel between your app to eSignal and from eSignal to the Data Manager and from the Data Manager to our servers.

I have not actually run across any quote API that will manager multiple data connections for you (w/o actually firing up multiple instances of that API).