Good Primer/Refresher for multithreaded programming?

sneakyimp

OK so I wrote some multithreaded code in college a long time ago but have basically forgotten everything about it. Can anyone recommend a really good book in multithreaded programming? Given how long it's been, I'm not sure if need a primer or a refesher.

PS: It doesn't have to be a book I guess. Online resources are great too.

sneakyimp

I googled around and found this book. Hopefully it will be good.

NogDog

And of course if you select a language with native multi-threading support (e.g., not PHP), you'll probably be off to a good start. 😉

Weedpacket

All I can recall is a rule of thumb which says something along the lines of: 1 thread per realtime I/O channel plus a maximum of one per CPU. Last time I used it was a screensaver app: one thread to watch for user activity and one to do everything else.

Otherwise I don't have much use for threading - but then I typically aren't doing much in the way of realtime I/O.

sneakyimp

NogDog;10903076 wrote:
And of course if you select a language with native multi-threading support (e.g., not PHP), you'll probably be off to a good start. 😉

Dammit! I love you NogDog, but I'm getting kind of frustrated by that 'JUST DON'T DO IT' message regarding PHP and multithreading.

I think I understand why PHP is not generally considered 'natively multithreaded' (see this famous note). Namely, because it uses a whole bunch of 3rd-party libraries that are not thread themselves threadsafe. However, in this thread, shrike says:

Shrike wrote:
On the subject of multithreading - PHP is thread safe, but not itself multithreaded. I believe there are some extensions which aren't thread safe. Also correct me if I'm wrong but Apache 2 should be run in it's prefork mode when using PHP, so is also not multithreaded.

I would VERY VERY much like to introduce more concurrency into one of my projects written in PHP which involves socket communications. Aside from socket communications, I'm not really using much else except for really basic PHP code. I've got a few of my own classes but all references inside those are basically primitive types: strings, integers, floats. The whole apache-related aspects of the aforementioned warning don't really apply here because I'm launching this code via command line. Is there any way we can have a more detailed discussion about what sort of concurrency/multithreading is possible in PHP? If PHP is threadsafe, can we not launch multiple cooperating PHP processes as a means of achieving concurrency in a project? I would imagine that MySQL might serve well as a data clearing house or pseudo shared memory tool.

I'm also wondering why PHP has functions like [man]pcntl_fork[/man] if it's not meant to be multithreaded. And what is this POSIX stuff all about?

If I cannot do this, it is likely that I'll need to bust my ass to learn more Java or C++ an rewrite a lot of cool code that I have. I feel it's worth noting that a large number of classes in the Java API are not threadsafe either -- at least they are marked as such.

BTW, an amusing excerpt from Threads Primer: A Guide to Multithreaded Programming here:

Bill Lewis & Daniel J. Berg wrote:
One of the major limiting factors is the problem of limited bus, memory, and peripheral speeds. We can build CPUs today that operate at 300MHz, but we can't build communications buses that operate at the same speed. RAM speeds are also falling further and further behind the demands of the CPUs. It is expensive to build 150 MHz CPUs, but as there are only a few in a system, it's affordable. To build memory that can keep up with these speeds would be prohibitively expensive.

Although this may seem a bit quaint, the book nevertheless is informative and I would recommend it.

Weedpacket

Forking a process isn't the same thing as starting another thread; the forked process is its own ... well, process, and handled by the OS as an entire executing program in its own right with its own entry in the process table, its own view of system memory and so on.

That said, I suppose you could use shared memory and fork processes that all use it.

Multithreaded applications are more common in Windows environments than Unix, because starting a process is such an expensive and heavyweight process in the former and a cheap and easy task in the latter (which is why the Unix httpd starts a whole bunch of child processes while the Windows Apache starts one process with a whole bunch of child threads).

It's also worth pointing out that Chrome's developers make a big point about it forking a new process for each tab/site that's visited; the level of isolation between processes makes it easier to kill off any that are misbehaving, and because responsibility for cleaning up after process termination falls on the operating system, not the application. The cross-talk that tends to develop between threads (unless you've got a clear and disciplined communications protocol about who's allow to write what where and who can read it when) works against all that. It's analogous to having functions communicate with each other by using global variables.