CODEWITHSUNDEEP
c#asp.netasp.net-mvcasp.net-web-apiconcurrency
Caribou
Caribou

Reputation: 71

Concurency thread and lock in ASP.NET

I’m wondering how asp.net handle “simultaneous” web requests. Let’s imagine a trading platform where traders can buy stock in real time. Every time a traders send an order, the system has to be sure that only one request can be in the trading thread. This to protect the integrity of the trade. To take an easy example let say, the system need 1 second to execute the order. During this 1 second all the others trade have to wait to be proceed one after another (this can be optimised but let say it is that simple for the sake of the example).

My question is how ASP.net manage concurrency and thread? If I use a lock on a sensitive part of my code, will all request created by asp.net enter the tread one after another? What is the best way to do that? How do every threads created by ASP.net interact with each other to be sure that another one is not already in the sensitive locked part ?

I hope my question make sense, ask me if it’s not clear.

EDIT : I should precise that the orders are send via webservices and that the user is expecting an answer ( success or fail).

Upvotes: 2

Views: 1441

Answers (2)

usr
usr

Reputation: 171178

ASP.NET really doesn't manage concurrency that much. All it does is accept requests and push them as work items to the thread pool. Eventually, the framework calls into application code.

What your app does, then, is your business. ASP.NET doesn't care. If you want to take a lock and wait, so be it. ASP.NET neither does want to know about that fact nor can it find out if it wanted to. To the system it just looks like your work items are taking quite long (because they are blocking on a lock).

There is no way to tell ASP.NET to call your trading system serially. You have to build that coordination yourself.

As you can see, synchronization inside of ASP.NET is similar to synchronization outside of ASP.NET. (I have glossed over quite a few details.)

Upvotes: 1

Eric Lemes
Eric Lemes

Reputation: 581

First, if you need something really fast for trading, forget about ASP.NET and consider client/server with socket. Is with this market usually uses.

I think for your problem you should consider an asynchronous design. Each web request sends the order to a service and this service executes against the market.

This "service" can be an windows service and you can use one of the following alternatives to enqueue all the trades on a single process:

1) ASP.NET sending orders to the service through Socket 2) Database (polling is terrible, but simpler to implement) 3) MSMQ or other implementations (RabbitMQ, Websphere MQ).

Other alternative is to synchronize the threads in the ASP.NET process using locks (take a look at the "lock" reserved word in C#). I don't think it's a good idea to block the ASP.NET thread while waiting for order execution.

Consider HTML5 WebSockets as an alternative too.

But consider your non-functional requirements. Usually this "low-latency" market requires performance.

Upvotes: 0

Related Questions