Multithreading tutorials

[bgd77]

Hello to everyone,

I want to develop some multithreading skills and I was wondering if you could recommend me some online tutorials (or books) with some theory and/or with examples in C/C++/MFC.

Thanks a lot!

[Eóin]

Taking advantage of some existing libraries can be a great idea since then you've documentation and sample code hand-in-hand. Two good one's I'm aware of are

• Intel Threading Building Blocks
• Boost.Thread

The Boost library would be a very steep learning curve if you've never come across Boost before. Codeproject would have loads of smaller, more accessible, examples. For example Synchronization in Multithreaded Applications with MFC. That might be more your thing if you don't want to go down the road of big libraries.

Another advanced source of expert advice would be Herb Sutter's "Effective Concurrency" columns.

[Jibz]

Just wanted to point to the quote in my signature about multi-threading .

[ecaradec]

A simple way to use threads is to share no data at all. Clone or allocate data then send them to another thread via PostThreadMessage or PostMessage and forget about them. In the other thread, when the loading, computing, ... is complete, post a message to the main thread with the result. It's very easy.

[f0dder]

Not sharing data (at least not for write) is good advice, since the required synchronization can eat up most of the performance you gain from going multi-thread. Threading is hard... it can be difficult parallelizing your algorithms, it's easy to fall into race conditions or deadlocks, and debugging thread-related bugs can be nightmarish (be glad when you do find them on your development system, though, since it's no fun when code blows up after distribution). Oh, and if you get all those right, then there's the possible performance issues - enjoy

[MilesAhead]

You can likely find some example source on
http://www.codeproject.com/

A good idea may be to look at some source from a threading class or component that seems to work well, from demos or applications etc..  IOW, if the guy's program doesn't hang and there's source, that may be a place to look.  Some components seem cool but as soon as you try to use 'em they crash.

If you do interactive apps(GUI type for example) a common requirement is to keep the GUI from "freezing" while a long background task grinds away. Often the thread types are divided into Windowed and Worker type... I forget whatever MFC I knew but I think it used that metaphor. A good exorcise is creating a GUI that launches a long task, that has a Cancel button that works.  For example, if the user starts calculating a checksum on a multi GB file and changes his mind.  Does he have to wait 5 minutes before the program "sees" he pressed Cancel?  That type of thing.

[maherjimmy]

Hi.......
This is Jimmy am fond of programming.
Currently working on project based on News teller.Well I use to print the approved articles and news daily from different computers sharing only two printers.Well the project is based on JAVA.Actually I know about miltithreading and comfortable with synchronizer in java.
But the problem of deadlock is always there in sharing enviorment.
Anyways I think that my knowledge should be more updated.So anybody has the solution for this problem then please post it to me,So as fast I can get rid from this problem.Your solution will be appreciated.

[MilesAhead]

One way you can control access to global data in a multi-threaded program, that's simpler than using a mutex, is the InterlockedIncrement() family of functions. The increment/decrement operation is guaranteed to be atomic. You don't have to worry about it being interrupted by another thread.

If you search on the term you should find example code.  If more than one thread has to alter the value of some global data frequently, it can be a lot faster than getting a mutex, altering some data, releasing the mutex etc..

Plus it's a lot less to debug.

[f0dder]

If you use the Interlocked* functions, be sure to check how to ensure they're using intrinsics for your compiler - it's not happening by default in VC++.

And while they're faster than the kernel-supplied synchronization primitives, keep in mind that it still means issuing a bus lock for the data. Sometimes you can get speedups by splitting up your data set, processing without locks, and recombining.

[MilesAhead]

That's a good point about the intrinsics.  You can't trust anything really works as named these days.  You have to see the assembler.  My first goal doing multi-threading would be writing apps that don't crash or deadlock.  If you are going to parse out separate copies of data then a variation on the fork() concept might be faster than threads.

I know when I process video, none of those multi-threaded encoders can keep up with multiple copies of an encoder esp. on multi-core PCs.  Each encoder is given a different range of frames to process and the results are all muxed together at the end.  Leaves multi-threaded encoders in the dust.

[f0dder]

Then those multi-threaded encoders must be coded pretty inefficiently - forking separate processes has more overhead. Surprises me, really - also when taking file I/O into account, encoders are usually pretty disk-heavy as well as CPU heavy, a single multithreaded process would have a better chance of being smart about disk I/O and avoiding disk thrashing than running multiple instances.

Sounds like bad programming to me

[MilesAhead]

I'd suggest trying a multitude of multi-threaded converters(is there a pun there or just a reasonable facsimile?) written by various programmers, then a gui supervisor app that launches multiple instances. Look at Core Temp to see which method maximizes the machine.  Although the multi-thread apps will use more than one core's worth of CPU, the average tends to be around 68% of available CPU power.  Whereas mult-processing apps like DVD-Rebuilder and FAVC the video encoding has the cores pegged at a nearly constant 100%.  Of course that's the part of the overall process that lends itself to multiprocessing.  The rest of the job you pretty much only run one muxer, one authoring app etc.. but even so it sure cuts down on the wait.

[f0dder]

CPU usage isn't necessarily the best indicator of efficiency, I'd rather look at what get's the job done quickest - but it is true that some (lots of) algorithms are hard to parallelize. I'd still say it would be more efficient to do the processing from a single multi-threaded application, though; if for nothing else, just for the ability to do I/O more efficiently.

I'm not familiar with the various video compression algorithms, but since many of them have the concept of keyframes, perhaps there's no dependency on the previous data stream once there's a keyframe - if that's the case, it might be possible to thread at keyframe granularity. Dunno if it'd be worth the possible code complexity, but it would definitely be nice to do all the encoding and muxing in one step.

[MilesAhead]

afa indication of efficiency I'd say the time to produce the video at the same or better quality is the measure.  The CPU usage indicator only measures CPU usage. The fact that the multiprocessing approaches seem to have in common that they maximize the use of the CPU power and get done quickest is surely coincidental then according to your theory?

[f0dder]

afa indication of efficiency I'd say the time to produce the video at the same or better quality is the measure.

Yep

The CPU usage indicator only measures CPU usage.

Yep

The fact that the multiprocessing approaches seem to have in common that they maximize the use of the CPU power and get done quickest is surely coincidental then according to your theory?

Huh?

What I'm saying is that if a multiprocess approach gets the job done faster than a multithreaded approach, the threaded version is coded inefficiently, since MP means more overhead than MT.

[MilesAhead]

I think you mistake efficiency for performance.  When I drive a steady 80 mph down the highway, my car isn't running as efficiently(miles per gallon) as when I drive 55 mph.  But I get there faster.  The multi-processing gets it done faster precisely because it's inefficient.  It hogs the machine and gets the throughput through!!

If you find any multi-threaded free encoders that work faster than assigning an instance per core please let me know so I can use them.

[f0dder]

I think you mistake efficiency for performance.

No, I don't - I'm saying that if MP gets better performance than MT, it's because the MT is coded wrong. MT should give both performance and efficiency. Remember the thread is about coding multi-threading - this is why I'm arguing MT>MP.

If you find any multi-threaded free encoders that work faster than assigning an instance per core please let me know so I can use them.

I haven't looked - but I somehow expect the "free" to be a bit of a problem. Multi-processing isn't easy to code

PS: doesn't the muxing stage take a fair amount of time? At least it did when I played around with DVD encoding a while ago.

[MilesAhead]

I know you are arguing but I don't see the proof in practice.  Just theory. If you have some practical examples I'd be interested.  Otherwise it's just arguing what should be rather than what is. I think we've reached an impasse unless you can provide some concrete apps I can look at. I've already done so.

[f0dder]

Well, you're claiming that MP>MT based solely on non-commercial software?

Again, this thread was originally about coding practices, not existing software. And I'll maintain (to my death!) that MT is usually going to be more efficient than MP... as long as the programmers know what they're doing. That a shitload of existing software is shoddily coded isn't an excuse to keep up that practice.