Back to Questions
1.0k
views3
comments
Threadpool - avoiding deadlock
f#

I'm using a lot of:

1

 x |> Async.Parallel |> Async.Run

...as well as some structural parallelism via Async.Spawn and MailboxProcessor

As I get more and more nested threads that want to queue on the thread pool, what is a good strategy to avoid deadlock?

Should I be mixing in more do!, let!, and return! into Async blocks?

.

(Luke has a vague thesis that there should only be one call to Async.Run inside any application.)

In any case, that's the only 'lock' I see from your description, and so assuming you are not using explicit locks or doing other crazy things inside the 'x's you're parallelizing, I think maybe there is nothing to worry about. I am being a little simplistic, but the nice thing about the Async programming model is it makes it way, way easier to write a bunch of code that 'just works' and avoid all the awful/nuisance defects that one is prone to make when using threads/locks/mutable-state-with-critical-sections/...

But feel free to talk more specifically about what you're worried about (if you have anything specific).

By on 4/9/2009 9:29 AM ()

I just checked I've only got one ``real'' Async.Run that works on a Seq. (The rest are simply converting an async block to a serial. i.e.: myAsyncFun >> Async.Run). (I'm not sure if it's a bad idea to convert it that way.)

And I don't do any locking except to write to the Console or log file (which should complete), and those writes should be fire-and-forget (Async.Spawn) calls by the owning thread.

Running through it mentally, there is nothing than can block. So, the threadpool should eventually get room to run a thread.

And it _does_ ``just work'', which sounds too good to be true. So, I thought there might be some case where the thread pool would fill up and nothing can run... or at least some gotcha!

More of general .NET question: Is it ``good practice'' to queue jobs onto the global thread pool? Should I be making a thread pool for myself to avoid problems in a larger application?

By on 4/9/2009 11:40 AM ()

Using the global threadpool is fine so long you aren't blocking for long periods of time, or use components that use the threadpool to do so. The problem then is that the threadpool is relatively slow to spawn new threads, so things might end up waiting a long time or timing out, depending on the app. For instance, a WCF-heavy app that makes sync WCF calls all over the place is going to need to expand the threadpool significantly.

I have a feeling this is a pretty major problem in general, and MS increased the default threadpool size to accomodate the many apps out there that were simply running out of threads since they blocked up the threadpool workers.

I think the new System.Threading has a way to manage a smaller threadpool so you won't as globally affected.

By on 4/9/2009 12:58 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper