Home/ Questions/Q 944433
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T22:35:30+00:00

( Edit : to clarify, my main goal is concurrency, but not necessarily for

  • 0

(Edit: to clarify, my main goal is concurrency, but not necessarily for multi-core machines)

I’m fairly new to all concepts on concurrency, but I figured out I needed to have parallel drawing routines, for a number of reasons:

  • I wanted to draw different portions of a graphic separatedly (background refreshed less often than foreground, kept on a buffer).
  • I wanted control about priority (More priority to UI responsiveness than drawing a complex graph).
  • I wanted to have per-frame drawing calculations multithreaded.
  • I wanted to offer cancelling for complex on-buffer drawing routines.

However, being such a beginner, my code soon looked like a mess and refactoring or bug-fixing became so awkward that I decided I need to play more with it before doing anything serious.

So, I’d like to know how to make clean, easy to mantain .NET multithreaded code that makes sense when I look at it after waking up the next day. The bigest issue I had was structuring the application so all parts talk to each other in a smart (as opposed to awkward and hacky) way.

Any suggestion is welcome, but I have a preference for sources that I can digest in my free time (e.g., not a 500+ pages treatise on concurrency) and for C#/VB.NET, up to the latest version (since I see there have been advances). Basically I want something straight to the point so I can get started by playing with the concepts on my toy projects.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The Task Parallel Library is definitely the place to look for simplifying your code. I’ve personally written a (semi-long) introduction to Parallelism with .NET 4 that covers quite a few concepts that would be useful.

    Be aware, however, that you probably will want to consider leaving your drawing single threaded. You should try to keep the computation multithreaded, and the actual drawing operations done on the GUI thread.

    Most drawing APIs require all actual drawing calls to happen on the same synchronization context.

    That being said, using the new collection classes like ConcurrentQueue simplify this type of code. Try to think in terms of lots of threads (producers) adding “drawing operations” to a shared, concurrent queue – and one thread (the consumer) grabbing the operations and performing them.

    This gives you a reasonably scalable, but fairly simple design on which you can build.

    • 0