Thread A reads variable X into register F.
Thread B reads variable X into register G.
Thread A increments register F.
Thread A writes register F to variable X.
Thread B increments register G.
Thread B writes register G to variable X.

Times X was incremented: 2.
New value of X: X+1.

Your absolutely right, the 'modify part' of ++X was so atomic that the operations didn't stomp on each other at all.


You default-constructed a rather large number of messages. If any of those constructors throws, you leak.


Exception safety, automatic memory release, and insurance against you screwing up.


I find it amazing that I both ignored it and quoted it at the same time!

JM: stop. You lost this argument a LONG time ago. Stop being a sore loser.

No, I won it the moment he claimed I didn't know C++, and I dropped a boost::spirit based recursive descent parser on him.

Except, as I stated, 'Thread B' cannot increment 'variable X' - only 'Thread A' can. On X86 a 32-bit store operation is guaranteed atomic, meaning that 'Thread A writes register F to variable X' will complete before 'Thread B loads variable X into register G'.

This is not the case on other systems: namely Alpha which only offers 16-bit granularity, and x86-64 (in 64-bit mode) which offers 32-bit granularity but a 64-bit size_t. My code is thread-safe but it's not terribly portable.

Fortunately there is nothing in any of those constructors which can throw an exception. Which is, also, why I did not make my message queue class a template.

1.) Don't need it.
2.) Doing that myself already.
3.) Where is the insurance against the STL vendor screwing up? For instance: http://www.dinkumware.com/vc_fixes.html
This is old, but Dinkumware periodically releases bug fixes for their STL implementation which are not made available for VC users. The STL is not 100% safe, my code is not 100% safe, your code is not 100% safe. Fortunately, unlike your code, mine is very simple so if there is an issue I'm going to find it before you will.

Okay, here's the rest of my last post you ignored:

Secondly, I never stated that volatile changes incrementation into an atomic operation. I stated that x86 guarantees that a 32-bit store is atomic.

It's called a ring buffer and the algorithm is as old as dirt. It's described in many places, and I am neither the first nor the last person to implement it. It was invented by people much smarter than you and used by a person much smarter than you. Also that last person was named Jon`C.

No, really? It's sure a good thing you're here to tell me that, because I'm apparently stupid and never designed my code to return an error value in that case or anything. I definitely am not using my very simple high-speed ring buffer to route messages between variable-sized message queues or anything like that, because to do that I would have to realize that my fixed-size buffer can possibly become full.

...unfortunately, while that solution is "better", it is also slower.

No, I claimed you haven't made/released anything. Which is true. Sith 2 may not be finished, but at least the code is out there. If someone wants to finish it they can.

Now all you've released is a painfully-convoluted mess of nonsense uncommented* code, using a template metaprogrammed recursive-descent parser, when not only Bison would have been a more appropriate choice but it would be much easier to maintain.

Kudos, I suppose. You sure showed me.

Loser.

(* = edit for completeness. Jesus Christ, no comments at all.)

And yet, thread B could end up using either value of X: The volatile does not guarantee that thread B will not load X while thread A is modifying it, but only that thread A will immediatly write it back.


Assuming that your code will never be capable of throwing an exception is naive, and just asking for trouble later.


1) Rather, "Don't need it now."
2) You didn't have to in the first place.
3) The STL was written by experts familiar with the internal workings of the compiler, and has inumerably more users than your code; and therefore, many many chances to uncover any bugs it might contain.



32 bit stores being atomic also doesn't make the modification thread-safe. They are an artifact of the architecture being 32bit. It would be absurd if the storage of a single machine word weren't atomic.

You needn't exaggerate: Dirt is very old. Whomever it was implemented and used by is irrelevant. I'm pointing out that I know what algorithm you are using, and how it works. (Plus, that article has a nice little diagram.)

So, when it fills up, does your writer thread spin until push returns true?

Actually, no, the CAS and CAS2 primitives can be implemented using the assembly intstructions cmpxchg and cmpxchg8b on x86 (And, actually, have to be in order to make the structure thread safe). The fact that the concurrency is handled by a single instruction is what makes that implementation fast.

It is a matter or whether or not it is worth reinventing the wheel. Why make a new Queue class if there is one available? In this case, the STL Queue did not satisfy the needs of Jon`C, so he made a new one.

Isuwen, I hate to take sides, but your code is much more difficult to read. I'm also not a huge fan of Boost, since they don't guarantee any sort of compatibility between versions and their libraries are a convoluted mess.

.

I have a rather lot of publicly available code, actually... and what I posted here isn't even part of it. And, heck, some of it's actually used by other people.

Now, we can argue about wether Bison would have been better: Well, no. Bison is another build step; clearly I would prefer to have it all contained (and hidden) right there in the source file. Afterall, that's what boost::spirit was designed for.

I won't defend my lack of comments, because I don't comment. But I read your comments, and almost all of them just repeat what the code says.

I think this is funny.

Mostly because the only coding I ever do is actionscript (and im not good at it) but Jons code is easier to understand...

Why are you so stuck on the concept of a volatile? I have explained exactly what the volatile keyword does in several occasions in this thread, but you keep obsessing over it.

READ THIS BECAUSE YOU ARE TOO DUMB TO FIND IT IN THE OTHER 8 PLACES IN THIS THREAD: I know exactly what volatile does. I know exactly how the compiler will treat a volatile variable. I know it has absolutely nothing to do with anything except guaranteeing that the variable will not be cached by the optimizer. <- READ THAT BECAUSE YOU ARE TOO DUMB TO FIND IT IN THE OTHER 8 PLACES IN THIS THREAD

It does not matter if thread B uses an old value for X because the old value will result in no action being taken.

No it isn't. This is low-level backend code I have not touched since last year. There is nothing below this class that can throw an exception. Nothing below this class even uses the new operator.

I will never need it.

But I did.

Fortunately I am the only user of my code, I know exactly how it works, and my code is called 1440 times a second. I'm waiting for your point.

The modification is thread-safe for exactly the same reason any other semaphore ever works.

On multiprocessor Alpha machines, machine word stores are not atomic.

Tower of Hanoi old then.

No.

That's super. So can mine.

If your code is so great and publicly available, how about your link to some of it?

Template metaprogramming is an afront to the Lord.

But... that's what comments are supposed to do.

Admittedly a number of my comments in that code are unneccessary (like "default destructor"), but your complete lack of comments is pretty damn retarded.

You brought it up as a reason why you could not use a dequeue.


So, your code is perfect and can never fail, because it was written by you?


Semaphores rely on hardware support for atomic increment/decrement operations. A multi-tasking OS can simulate the support by pausing the task switching.

They are if both threads are running on the same processor. It's only an issue when multiple processors write to the same location at the same time. The hardware serializes memory access at the byte level instead.

Okay, that's pretty old.

Does it just forget about the message? Is it lost? Does the system abort? What happens?

So can yours what?

Sure! I wrote a preprocessor addon for the scripting language AngelScript. http://www.angelcode.com/angelscript/extras.asp Ignore the ugly HTML, it's just a dump of my readme file.

Then I have sinned.

Absolutely not! http://en.wikipedia.org/wiki/Comment

No, I brought it up as something I would have to do in order to use one.

No. However, if my code does fail, I will be able to fix it.

Correct: other semaphores work because an update to the semaphore is atomic. I'm glad we agree.

This is what I said earlier in the thread. And, actually, the hardware serializes memory access at the 16-bit level.

Not the... you know... creation story, but the mid-1800s mathematician old.

The message is not removed from the queue.

Be implemented much faster using x86 assembly, just like most other programs.

Incidentally, your argument that the algorithm is much faster than mine is because it can be implemented in a single instruction (cmpxchg) is flawed. How many cycles does that instruction take? 3? Throw that on a multiprocessor machine and suddenly your operation isn't atomic.

Fantastic.

I'm on my second scripting language. But your plugin is good too.

Pedophilia is a sin too FYI.

Yeah, we can argue over "proper use" of a comment all night, but everybody universally agrees that your complete lack of comments is stupid.

Actually, it being atomic is the very reason for it's existence.

WTF is wrong with you? I ignored you the first time you did this because I thought you were just being a tard. You going to make more baseless claims, or go surf kiddie porn sites manufacturing evidence?

cmpxchg is only atomic on single processors. Multiprocessor code requires a lock prefix, which is substantially slower.

When Jon'C does a push-up, he pushes the earth down. [/SIZE]

When Jon'C sneezes it is a funtion used to leech extra smart from his brain.

This smart is quickly replaced.

Also, Jon'C never sneezes because he has an infinite capacity of smart.

Reasons not commenting is :downs:

Situation 1: Open Source

You release your project (finished or not finished). Another person would like to modify or improve a portion of the code. He jumps in the file, and attempts to find the function he is looking for. He starts skimming.

Tell me, which is faster to skim? A bunch of code using archaic function names and made up names used by the original programmer, mixed into a crapload of operations, or a single comment line that states "This function grabs the mouse"?

Situation 2: Time flies...

You put a project on hold, for whatever reason. A year later, you find it sitting in a corner of your hard drive. You decide to finish it, and crack it open. You find an error, and locate the function causing it in the code. But now you're staring at the function, wondering just what in the bloody hell this function was supposed to do in the context of the entire program. You spend hours tracking down all the linked custom functions and variables to find out what you were doing with this function so you could fix it without breaking it.

Or you could have just written "This function calculates the FPS being obtained by the renderer." and realized it wasn't terribly important in the first place.

Situation 3: What was that input?

You wrote your own function an hour or so ago to handle keypresses. Now you're ready to use that function later in the code. But alas, you have forgotten the syntax for your function. Was the first value supplied the status of the key, or was it the key pressed?

Now, you could go back to the function and burn through it to discover the proper order and expected type (were you using characters, or did you need to convert to ASCII number first?), or you could read your handy cheatsheet comment at the top that gave a good example of what the function expects.

But hell, what do I know, I only program PHP and HTML.