Cluebat-man to the rescue

A weblog dedicated to Visual C++, interoperability and other stuff.

Don't people read anymore before commenting?

Blogs are funny things. We all have different reasons to write blog posts. Apart form the general stuff that almost everybody sometimes writes about (opinion pieces, general comments about something or other) I like writing tech articles.

Programming is my hobby, and sometimes I like to set myself a challenge, or want to see what sort of interesting things I can do with a given API / language / platform. Afterwards, I write an article about what I did, partially because I actually like writing things like that, and partially because you don't know if you understand something fully until you can sucessfully explain it to someone else, leaving out no details.

You'd be amazed about how many things you take for granted until you are forced to explain them step by step. And you'll quickly find out that some things you've never thought about twice were wrong.

Anyway,  It takes a lot of time to write a detailed article about something technical (much longer than you'd expect). And I always hope that if you care enough about it to comment on it, you've actually read it. But sadly, I am often disappointed.

Take this article for example. I wrote it as an example of how it is possible to create a fifo queue without locks. In the article I mention that there is 1 writer, and 1 reader, and that my implementation is thread safe, specifically because of that. And after all, this is a simplified proof of concept of something, so lack of advanced features (like signalling) is to be expected.

And yet a lot of people comment the same thing every time 'Your code is wrong, this bit has a race condition. this is a basic mistake' and variations thereof. And then I think to myself 'Yes, of course there is a bloody race condition. That is why I mention that there should be only 1 reader and 1 writer!' What makes it even worse is that a number of people already commented this, and that I've already answered that comment several times.

I am definitely not a prima donna programmer. I never mind explaining something about my code or design, even if I have to do it a couple of times. And I really welcome comments, bugreports and other feedback about my code. If I made a mistake, I'd like to know. But I hate it when people start spewing comments without even bothering to read the article and / or the comments that have already been posted. Is it really that hard not to make an idiot of yourself?

Posted: Dec 03 2008, 04:37 AM by vanDooren | with 2 comment(s)
Filed under:

Comments

Majkara said:

What you need to do is a test case and prove it.. once you do ( and I doubt you will write one that will not fail every 7 hours or less)..

I agree they didn't read on single writer, single reader..

But now, you have to ask yourself, where is the proof? You might be just lucky and you are.

People already pointed out to you, you MUST have barriers for it to work. You didn't listen there at all.

Also, volatile is not the way to do it, and volatile on array is just nonsense.

# February 8, 2009 7:07 AM

vanDooren said:

This code is a simplification of production code used in real-time spacecraft ground systems.

Bascially I ripped out the event notifications, and some other stuff that is not to the point.

Just giving a test app is not going to prove anything, because you can't prove threadsafeness with an example. You can only do so by formally working your way through the code.

But when I was debugging a system for which I was the lead developer, I did a lot of testing and analysis.

One of the things I did was to host a bunch of these queues in a process (they acted as message delivery workers) and then have a dozen processes running in parallel, each posting bursts of messages in their dedicated queues, which were read by the scheduler.

The messages were written in short bursts, at random time intervals. This ran on a dual CPU machine for 24 hours, resulting in billions of messages transmitted and received, all accounted for and all in perfect condition.

The reason I didn't post that test code is that

a) it didn't belong to me

b) it ran on unix

c) it was highly application specific (names etc)

Memory barriers are only needed on platforms that perform reordering (which was mentioned) but x386 and x64 do not.

the only thing you need is volatile, to make sure the compiler doesn't operate under the assumption that values remain the same between instructions.

Using volatile on arrays is not nonsense btw:

msdn.microsoft.com/.../145yc477(VS.80).aspx

In C, arrays and pointers are treated the same.

# February 8, 2009 4:10 PM