>>...Would it be possible/useful to make something like this work?

No. You need to define a C++ operator '>>'. I did a verification and this is what I had:
...
...Error C2679: binary '>>' : no operator found which takes a right-hand operand of type 'tbb::atomic' (or there is no acceptable conversion)
...

Actually, a simple workaround works (!) and here it is:
...
tbb::atomic< char > q;
std::cin >> ( char & )q;
...
Note: Tested with VS 2005 and TBB v4.0 Update 3

Ouch, that hurts! I have a special place in my heart for atomics, and this is not how they should be treated, for various reasons, not all of them pedantic, even if at first sight that "simple workaround" seems to be working (I'm surprised that you didn't get scolded by the compiler for doing this?).

It's easy enough to define a specific istream overload instead, something like "static inline std::istream& operator>>(std::istream& is, tbb::atomic<char>& a) { char c; is >> c; a = c; return is; }", or something that actually compiles (it probably does, but I haven't tested), or something with templates to accommodate more types. But at the same time you probably wouldn't want that as a standard part of the library, because there's probably no simple way to specify memory semantics (I don't think a manipulator can be defined without bridging the whole family of stream classes?), which is relevant because there's a conflict between what probably applies (relaxed, which is cheap) and what's the safe default (sequentially consistent, which is expensive and is assumed above by the assignment operator), so it even seems better to define a regular function with an explicit name than a fancy-looking operator.

I may have left some doubt in my reply above: what was troublesome was the suggested workaround with a cast, but a local stream operator definition should be all right (if used wisely). Also, I've now "unvanished" the tbb::atomic template parameter "char" (using lt/gt references).

>>...This is something that I decided to try...

Raf, I think you're over-reacting because I also decided to try it, let's say just for interest... and I promise you that I will never-never again use ( char & ) cast with 'atomic'. Merry Christmas!

Best regards,
Sergey

I hope I didn't overreact so much as try to be clear about several possibly relevant aspects (with a touch of humour, in case this was not obvious).

So was there really no complaint about breaking strict aliasing rules, or did you not enable them, or are C-style casts and/or references excluded, or did you ignore what the compiler thought of this, or something else?

Sergey, I think

std::in >> (volatile char&)q;

would be more syntatically correct, however the >> operator might not accept volatile.
What you want to assure is that q is actually written as oppose to held in register.

Jim Dempsey

I see that discussion continues... :)

>>...It won't. I tried to write into a volatile...

Here are a couple of test-cases with a Visual Studio C/C++ compiler ( just for your reference ):

[ Test-case 1 - Compilation Error ]

volatile char chExit1;
std::cin >> chExit1;
...
Error C2679: binary '>>' : no operator found which takes a right-hand operand of type 'volatile char' (or there is no acceptable conversion)
...

[ Test-case 2 - Compilation Warning ]

volatile char chExit2;
std::cin >> ( volatile char )chExit2;
...
Warning C4197: 'volatile char' : top-level volatile in cast is ignored
...

[ Test-case 3 - Compiled without any Warnings or Errors ]

char chExit3;
std::cin >> ( char )chExit3;

[ Test-case 4 - Compiled without any Warnings or Errors ]

char chExit4;
std::cin >> ( char & )chExit4;

Merry Christmas, a.c.sant!