3 ms·

Another reason threads haven't become more popular is because operating system support is generally poor. I'd say that on Windows threads are first-class citiz

Another reason threads haven't become more popular is because operating system support is generally poor. I'd say that on Windows threads are first-class citizens and are very actively used. Windows even comes with a ready-to-use thread pooling and ability to run arbitrary code in different thread contexts. Moreover, Windows-specific documentation often has a special paragraph regarding thread safety for every clib/stl function. When I moved to Linux world I indeed found that threads aren't treated well. In fact I still don't have a full and deep understanding of threading outside of Win32, I suspect because different UNIXes have them differently. Perhaps it's the lack of POSIX standardization what makes them scary. I've built a few multi-threaded windows server-like services and never found them to be particularly difficult to grasp or debug: system APIs, docs and tools were excellent. To summarize, only after becoming a full time Linux/OSX programmer I finally started to see why Internet is full of "threads are evil" articles.

graemep 18y ago
I think part of the reason is that Linux and Unix processes are less expensive to start, they are more memory efficient because shared libraries are loaded into memory only once (not once per process) and fork is copy on write. I may be wrong about Windows. I recently tried a Tcl script that launched another Tcl script repeatedly and found additional memory consumption was about 100kb per process. It wold probably have been less if I used fork. It would be interesting to know how Windows compares.
- michaelneale 18y ago
  Traditionally processes were very expensive to start on windows, threads very cheap. On linux its much of a muchness (or was, probably still is). Windows would be less then that per thread, probably more per process. But I am thinking back to 2003-ish data ! (really should try some experiments again).
- old-gregg 18y ago
  Correction: shared libraries (DLLs) on Windows are shared between processes exactly the same way as it works on Linux, they're called 'shared' for a reason :-) They get "mapped" into virtual address space of every process, but physically there's only one copy, moreover, if you're running as an Admin, a process can alter the code in a shared DLL, causing it to work differently in all other processes that use it, that's one of the tricks that infamous rootkits do to hide themselves. You are right, Windows processes are heavy. Moreover, context switch between processes on Windows is also a little slower, because NT-based kernels went "maximum security" route and perform full process isolation, that's also why Windows doesn't have a fork-like syscall, only environment variables, IIRC, can be cloned. (which is how, I suspect, Linux threads are implemented - they're probably share-everything fork calls). On the other hand thread/fiber switch on Windows, I believe, is fastest of all popular x86 OSes. All in all I like Windows process model a lot more. Clear separation between processes (share nothing) and threads (share everything except the stack) is well-known and well documented, and leads to a much nicer server-like application programming experience. Although... I really like how easily you can nuke frozen processes on Linux if there is a problem. No programming tools/knowledge required. Dealing with hung threads would have been a lot harder.
blasdel 18y ago
Linux threads are just processes that share their whole address space read-write. There's no special thread primitive.

graemep 18y ago

I think part of the reason is that Linux and Unix processes are less expensive to start, they are more memory efficient because shared libraries are loaded into memory only once (not once per process) and fork is copy on write. I may be wrong about Windows. I recently tried a Tcl script that launched another Tcl script repeatedly and found additional memory consumption was about 100kb per process. It wold probably have been less if I used fork. It would be interesting to know how Windows compares.

michaelneale 18y ago
Traditionally processes were very expensive to start on windows, threads very cheap. On linux its much of a muchness (or was, probably still is). Windows would be less then that per thread, probably more per process. But I am thinking back to 2003-ish data ! (really should try some experiments again).
old-gregg 18y ago
Correction: shared libraries (DLLs) on Windows are shared between processes exactly the same way as it works on Linux, they're called 'shared' for a reason :-) They get "mapped" into virtual address space of every process, but physically there's only one copy, moreover, if you're running as an Admin, a process can alter the code in a shared DLL, causing it to work differently in all other processes that use it, that's one of the tricks that infamous rootkits do to hide themselves. You are right, Windows processes are heavy. Moreover, context switch between processes on Windows is also a little slower, because NT-based kernels went "maximum security" route and perform full process isolation, that's also why Windows doesn't have a fork-like syscall, only environment variables, IIRC, can be cloned. (which is how, I suspect, Linux threads are implemented - they're probably share-everything fork calls). On the other hand thread/fiber switch on Windows, I believe, is fastest of all popular x86 OSes. All in all I like Windows process model a lot more. Clear separation between processes (share nothing) and threads (share everything except the stack) is well-known and well documented, and leads to a much nicer server-like application programming experience. Although... I really like how easily you can nuke frozen processes on Linux if there is a problem. No programming tools/knowledge required. Dealing with hung threads would have been a lot harder.

blasdel 18y ago

Linux threads are just processes that share their whole address space read-write. There's no special thread primitive.