[Interest] QMap and thread-safe.

[Mandeep Sandhu]

On Thu, Jul 25, 2013 at 12:59 PM, Till Oliver Knoll <
till.oliver.knoll at gmail.com> wrote:

> I think the answer has already been given with regards to "mutable" and
> "const_cast", but at least I seem to have missed at least one reply (sent
> in private?) in this
>

No, no private replies to me at least! :)


> discussion. So here are my thoughts :)
>
> Am 24.07.2013 um 09:29 schrieb Mandeep Sandhu <mandeepsandhu.chd at gmail.com
> >:
>
>
> Microsoft is giving a "mutable" example with an access counter:
>
>   http://msdn.microsoft.com/en-us/library/4h2h0ktk(v=vs.80).aspx
>
> If that increment was not atomically implemented (and to be honest, right
> now I don't know whether a "foo++" is atomic - I don't think it is, is it?)
> and again two threads
>

Atomicity of foo++ would depend on the data type of foo, right? Maybe if
it's a short, the increment will be atomic. Thought the correct way would
be to use atomic types (or maybe use the gcc atomic extensions).



> Bottom line: you walk on a very thin line when breaking the "const" with
> "mutable" (or "const_cast"). You can totally mis-use it and render the
> "const" completely meaningless, you can now rant about C++ letting you
> shoot into your foot (once again) and how "const" does not give you /any/
> guarantee about thread-safety (as long as only "readers" are involved...
> (even though I understand that "reader-thread-safety"  is now the
> *intention* of the C++ 11 standard library...)
>
>
> But think about it: having a loophole such as "mutable" is actually
> (ironically?) the only way(1) to make a class thread-safe while still
> offering const methods! (Java for instance does not even have the lan
>


> guage concept of "const methods").
>

Yes, the irony is unescapable! :)

Thanks,
-mandeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130725/83fcd25c/attachment.html>