POSIX Threads vs. Win32 Threads

Question

I just dipped my toes into the POSIX pond and tried out POSIX threads for the first time. Until now, I'd been under the impression that there's a big architectural difference between POSIX threads and Win32 threads, but from the (admittedly little) that I tried, I didn't really see any difference.

I'm still curious though -- what are the differences (if any) between POSIX threads and Win32 threads? Are they different fundamentally, or do they just have minor differences?

Solution 1

There are huge differences between how threads are managed and scheduled "under the hood" in Windows NT family kernels and on many Unix kernels, but that's not the question.

If you're just talking about the interface (the services exposed by Win32 threads and POSIX threads), with some work you can almost map any POSIX thread feature to a Win32 equivalent ~1:1. And it has been done (see pthreads-win32).

One big difference I may notice is that under Win32 you use actual system calls to work with threads, instead POSIX threads' calls are part of a library (pthreads), that - under many Unix systems - calls some very low level system calls of Unix kernels (under Linux there's clone()).

Just to prove you that, unless you go very deep, pthreads is nothing so special, you can download pthreads-win32 that exposes quite the same interface of pthreads, and any function is mapped on Win32 thread APIs. And it works.

Solution 2

One small but crucial difference seems to be that there's no POSIX equivalent to Windows's CREATE_SUSPENDED.

Comments

[user541686]

+1 Huh, now I'm curious to know how they're different "under the hood". :-) Would you please mind elaborating if possible, or pointing at some page where I could read about it? It seems interesting.

[gd1]

@Mehrdad: I've been studying the internals of Win32 and (some) Unix kernels (especially scheduling) at the college, but I don't remember all the details and it's stuff that can't be written on a comment. Just an example to give you a glimpse. Under Win32 threads that are back-from-I/O (have just requested some I/O and they're done) are promoted by one priority level (+1) - we do prefer I/O threads to be scheduled before because they may regard user interaction and waste less CPU - under some Unix kernels they're promoted many levels up and stay on top if keep on being I/O bound...

[gd1]

@Mehrdad: but that's rather simplistic. You may want to know more, and I can point you some good (technical) book. Give me half a day and I'll find my S.O. book.

[Hi-Angel]

I disagree on one-to-one correspondence. Though I'm not very good with multithreading API, but one thing from pthreads that comes to mind is signal. WinAPI have no way to set a handler for a particular signal in one thread, then send a signal from another thread to the first one, forcing it to interrupt the current code, and execute the handler. That was a big problem when I had to port some app prototyped in GNU/Linux to Windows with C# — such, seemingly, "ordinary" functional turns out to be unavailable on Windows, crushing down abstraction layers.

[user541686]

@Hi-Angel: I thought signal handlers are asynchronous? How can you just randomly "interrupt" a thread without warning? Are you talking about QueueUserAPC or SendMessage perhaps?

[Hi-Angel]

@Mehrdad here's a quick and dirty example of signals with pthreads. For demonstrating purposes I didn't even put in the second thread sleep(), i.e. it doesn't call any system functions, rather just repeating the same code. The first thread after 1 sec. sleep, sends SIGUSR1 signal to the child, thus forcing it to execute the handler, which in turn exits the child. The example would work on most modern operating systems. Won't work on Windows though.

[user541686]

@Hi-Angel: Isn't that extremely dangerous? What happens if the thread holds a lock? (e.g. if it's allocating memory?) What if it's mutating a data structure? Isn't it almost guaranteed to break something?

[Hi-Angel]

@Mehrdad I didn't see a problem — the thread would execute the handler, then return to where it was, so nothing would left in indeterminate state. I guess though there probably are places which can not be interrupted, e.g. when the execution is in the kernel. And, of course, as usual, there's always a place for abuse — for example one may set a handler for «segmentation fault», which would return to where it was instead of exiting — but that's up to programmers ☺

[user541686]

@Hi-Angel: "I didn't see a problem"... do you see why you can't even do something as mundane as calling malloc inside a signal handler? And, considering this, could you explain to me why you think signals are any better than just creating a new thread and running that instead? The latter is safer and less restrictive.

[Hi-Angel]

@Mehrdad that's interesting. Tbh when I answered, I didn't think about a problem in the handler when the same handler is suddenly called again; but neither I knew about the malloc problem, thx for the link. I didn't see though a relation between that and your question — if you need a new thread, just create one. Signals (from the user viewpoint) are usually used for things, like getting an info about a progress from a thread which is busy with a very long work.

[user541686]

@Hi-Angel: I don't think progress reporting is a proper use case of signal handlers, it's closer to a misuse... proper progress reporting shouldn't require asynchronously interrupting random threads.