Who knew… that pthreads Condition came to Windows?

Not me! Until I happened across the SleepConditionalVariableCS function doc.

It seems like it’s been fairly well known that implementing POSIX condition functions on Windows synchronizations is hard. Here is one explanation of the pitfalls. However, time moves on, and as long as you are not using Windows 95, ME, XP, or Server 2003, Windows now has a posix-condition-like native synchronization primitive. Also rather cool is you get to choose whether you want to use a CriticalSection or a slim read-write lock .

Anyway, as long as you are willing to compromise a little on your platform support (and today that suits me fine) it becomes really trivial to do a pthreads compatibility layer for Windows. Which makes me wonder: Why hasn’t Microsoft done it already?

Well maybe Microsoft has? Apparently there is something called ‘Interix‘. That I had also never heard of until today, although it’s been around for a few years. It’s a ‘UNIX on Windows’. You live and learn my friend. I was not too sure exactly what it includes, so I decided to learn some more…

https://brianreiter.org/2010/08/24/the-sad-history-of-the-microsoft-posix-subsystem/

It’s a sad story indeed. It seems to be one of those ‘death by success’, as in the Interix thing was successful in getting itself widely distributed by virtue of being included into Windows… except not really, because it couldn’t get GNU utilities included - because of licensing, there is little doubt.

It also sounds like a contributing factor may have been ‘death by losing the key people with key knowledge’. If the product got transitioned across to India, that means that suddenly the people who own shipping the software don’t know much about it. Sadly I’m in exactly that sort of scenario right now, being one of the new owners of a piece of software that just got shipped across back from India after having previously being shipped there.

It can really feel bad being responsible for a giant mess of code that you don’t understand. An obvious temptation is throw it away and start over, just so you’ll understand everything. The right choice, on the other hand, if you want to keep that product is I believe obvious. Don’t throw it away. Don’t start hacking new features onto it. Understand it first. And understand it fast!

Anyway I’m getting very sidetracked. Must get back to my grafting compatibility.

Oh yeah, one more diversion. I saw an amusing thing on slashdot about POSIX vs Windows threads.

https://www.developers.slashdot.org/story/07/02/26/1211220/Pthreads-vs-Win32-threads

Of course the amusing part of this is not the post or the article linked, but the comment thread. Only they’re not really proving each other wrong. They’re just people who have noticed different things. And depending on what you notice first, you tend to jump to a different conclusion.

* There’s people who noticed the structural similarity of the article. The comment where they show a diff is particularly amusing. Many of these people are supporters of the Windows forced a retraction theory. Another possible logical theory is that the job of the guy who writes this article is to generate publicity, and he deliberately rewrote his old article using the same structure because that was the easiest way to write an article and generate publicity, who cares about consistency if it gets you eyeballs after all?

* There’s people who noticed it’s a Windows vs POSIX fight and the poster is an Intel blog. Obviously Windows is a very big customer partner of Intel, and on this basis it makes sense to believe someone at Windows might have complained and eventually the article was rewritten as a retraction. This also can explain the structural similarity. (I have no idea if this theory is true.)

* Then finally there’s people who looked at the APIs logically, and tried to rationally dissect which is better. You may notice the argument for POSIX seems a little weak because it’s mostly about ‘strong separate typing’ being good because stupid programmers won’t mix things up accidentally. Whereas the argument for Windows and against separate synchronization is that all of the synchronization primitives actually have something in common, which is that you can wait for them. So why not have an API which lets you wait for them all? And in fact any mixture of them, which is therefore something that is much more powerful than what you can do in POSIX’s separate constructs model. Some of these people seem supporters of the innocent ‘he probably just changed his mind’ theory. Their case is somewhat weakened by the fact the author didn’t make any kind of retraction or mention that he’d changed his mind.

 

Of course, in the end the guy (Clay) responded. And it turns out that his answer is the one I initially felt might be true (after having also worked with both pthreads and Windows threading models and before reading slashdot comments). He just changed over time. He wrote the first article when he knew pthreads well and Windows threading not much. PThreads were nice and familiar. He wrote the second article when he knew Windows threading well and had forgotten pthreads. The liking is explained by familiarity, the textual similarity is explained by laziness.

Moral of the story: people and their opinions change all the time, and typing is hard work. OK that’s really enough from me now.