Other Software > Developer's Corner

Multithreading tutorials

<< < (2/4) > >>

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page