Jump to content
  • Advertisement
Sign in to follow this  
Eric_B

[.net] Asynchronous calls, thread pool, and blocking woes

This topic is 5476 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

My teacher told me not to use any code that blocks a thread in asynchronous functions, because .Net runtimes use thread pool in asynchronous calls. If I do then it will cause more threads to be added to the thread pool, which is in efficient and will harm performance. How should I get around this problem? Thanks in advance

Share this post


Link to post
Share on other sites
Advertisement
You will have to be a bit clearer than this...

The threadpool will only be used when you do not create the trhread yourself. Of course blocking a asynchronous thread should be done as little as possible, allthough waiting on input via a stream never hurts...

Could you explain the problem a bit more?

Cheers

Share this post


Link to post
Share on other sites
Quote:
Could you explain the problem a bit more?


Well it is proxy application that stands between user requests and MS SQL database. Whenever a user sends an sql query, the proxy loads an asynchronous procedure to process the query.

I made this asynchronous procedure by using standard .Net BeginInvoke and EndInvoke methods, but I'm worried about the performace issues.

My teacher told me once that these methods shouldn't be used if there is a blocking code in the delegate function or it will load too many threads and harm the performace.

So how do I get around this problem?

I hope this helps.

thanks

Share this post


Link to post
Share on other sites
Be aware that the asynchronous methods in .NET don't necessarily use a thread. For quick and dirtly example of how this is true for socket programming, let's say, check out this blog post by Ian Griffiths. It is important to understand whether a thread is *really* being allocated or if it just seems that way. An asynchronous call != new thread. The blog post above shows a quick and dirty server that handles anywhere from 100-1000 incoming connections, yet only uses ten threads.

I think the emphasis that should be put on what your teacher says is that no "blocking" code should be in an asynchronous process. I don't think the biggest worry is about allocating too many threads though. .NET can usually handle all that stuff (and there is a set maximum limit of threads in the thread pool). If your requests take longer than normal than you will see you response times tank. The bigger concern with blocking code is race conditions and deadlock.

Let's say that request #1 locks resource #2. Then request #2 locks resource #1. Well, if request #1 then tries to lock resource #1 before releasing resource #2, then request #1 will be waiting for request #2 to unlock its resource. However, request #2 is waiting for request #1 to unlock its resource, and hence, a deadlock has occured.

Is there a specific example of blocking code that you are worried about? The biggest "blocking code" to worry about are locks that are put in place for multithreaded safety.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!