Important Linux update

[F. Bluemers]

http://software.intel.com/en-us/blogs/2 ... x-threads/

[Christopher Conkie]

I always thought POSIX was better. Is the opposite true now?

I wonder what the linux people will say to this.....

Christopher

[bob]

I always thought POSIX was better. Is the opposite true now?

I wonder what the linux people will say to this.....

Christopher

That it is nothing more than the usual "windows bigotry". The guy fails to discuss something that is "slightly important" which is performance. Of course, the windows guys have _never_ given a hoot about performance anyway so that's not news...

[ilari]

I always thought POSIX was better. Is the opposite true now?

It's some guy's opinion. Doesn't make it true.

I'm surprised that he actually considers the HANDLE data type as an advantage for Windows. I've written low-level code (threads, processes, pipes) for both POSIX and WinAPI, and the fact that almost everything is a HANDLE was a pain in the ass. The great thing about statically typed languages like C and C++ is that the compiler can detect when the wrong data type is used. That fails when all the functions accept HANDLE types. And of course some HANDLEs can't be used with some functions that operate on HANDLEs, so what's the point, other than confusing developers?

[frankp]

The main reason seems to be missing: 'we don't own and control POSIX, so the M$ API is better - and of course _the_ Standard.'.

[wgarvin]

I've always thought of Windows threads as being tragically heavyweight and slow. A well-designed microkernel (a REAL microkernel, e.g. L4 or neutrino) can create, destroy, context-switch and schedule threads a lot faster than Windows. Or at least, that used to be the case 10 years ago, maybe modern Windows on modern CPUs has caught up a bit (but I really doubt it).

One of the conclusions of the L4 project was that to make a truly fast and awesome microkernel, the implementation will be largely processor-specific (e.g. even different cache characteristics can mean you need to rewrite parts of the microkernel for best performance; I vaguely recall they had an 80486 implementation and a Pentium implementation, and the memory layout of process control blocks was quite different between the two because of cache differences [edit: or maybe it was TLB differences, or something.. can't recall the details]). The NT kernel is not very micro, and they don't write a separate implementation of its threading stuff for each processor. Plus all the extra crap to do with their funky thread scheduling rules, and queues of APCs, and synchronization object stuff, probably adds a bunch of overhead to the raw thread switches. Windows thread context switches are probably at least 10x slower than an good microkernel.

I have no idea whether POSIX threads on Linux are any faster than Windows, though.

As to wether the Win32 thread API is well-designed: I'd say its not too bad, especially considering that most of it is at least 15 years old by now. It could be better, and I wouldn't use HANDLE as any kind of example of goodness. Like Ilari said, its clumsy to work with things that all claim to be HANDLE when they have different properties and only some subset of them works with certain functions... About the only function that will work on every handle is CloseHandle(). Did you know that on 32-bit versions of Windows from 95 up to at least XP, an HMODULE is actually the base address of that executable or DLL in your process's virtual address space? On NT-based windows, nearly every other type of handle is some sort of index into a kernel table, but not HMODULE! Did you know that GetCurrentProcess() does not return an actual handle, but rather a "pseudo handle" which is only accepted by some of the functions dealing with handles, not all of them (though at least the ones that expect process handles, will deal with it correctly!). It has the value of (HANDLE)-1, which the MS API docs politely asks you to please not hard-code into your program in case they ever change it in the future. Except that they can never change it without breaking backward compatibility with any badly-written programs whose authors didn't follow the rule. In the win32 world, if an API rule is not strictly enforced by the operating system, then what you get is badly-written programs in the wild that break that rule, and then five years from now a new MS operating system comes out and those programs don't work and everybody blames Microsoft for it. (hee hee!)

Also: Convincing the Windows scheduler to schedule your threads the way you want it to, can be a real pain.

Oh, Ilari: Did you know that you can #define STRICT before including windows.h and all the handle types will be defined as pointers to different C/C++ structs to prevent you from mixing them up without explicit casting between them? That's okay, neither do 80% of the Windows programmers out there, judging from the amount of win32 source out there that doesn't use that feature (hell, I don't even use that feature).

Anyway, sorry for the random digressions.

[Pradu]

http://software.intel.com/en-us/blogs/2 ... x-threads/

I saw this post a really long time back. Basically the guy posting it wanted to start up a lively discussion comparing Windows threads and POSIX threads. Here's a post by the same guy saying that "POSIX threads are better than Windows threads":

http://software.intel.com/en-us/forums/ ... pic/47437/

[F. Bluemers]

doh
well,That last one if from May 2003
the other one from October 2006.
He just gained insight
Best
Fonzy

[michiguel]

doh
well,That last one if from May 2003
the other one from October 2006.
He just gained insight
Best
Fonzy

http://www.cs.wustl.edu/~schmidt/win32-cv-1.html

Aren't condition variables an important feature?

Are they available only in Vista or what?
http://msdn.microsoft.com/en-us/library ... S.85).aspx

Miguel

[bob]

doh
well,That last one if from May 2003
the other one from October 2006.
He just gained insight
Best
Fonzy

http://www.cs.wustl.edu/~schmidt/win32-cv-1.html

Aren't condition variables an important feature?

Are they available only in Vista or what?
http://msdn.microsoft.com/en-us/library ... S.85).aspx

Miguel

These things have been around forever, and have been available in POSIX threads for that same amount of time. I don't use them at all in parallel search, however.