Re: C++ Threads, what's the status quo?
Mirek Fidler wrote:
Peter Dimov wrote:
Next up, we have the modern STL, where it's possible to read the same
instance from multiple threads. This is also the thread safety level
for all basic types, both de facto and as specified by the POSIX
standard. ("Basic" thread safety, the most useful level in general;
should be the default for all sensible C++ code.)
Well, I am not sure. Consider internal caches implemented using mutable
members (or, heavens forbid, const_cast ;). In that case, your "basic"
requirement would mean that ALL mutable members must have serialization
(locking) around them. That is IMO not a very good idea.
You get to choose the thread safety level for your component. If you
want concurrent reads to not be allowed, then you document them to not
be. "Default is basic" only says what happens when you don't explicitly
state otherwise. Since most components provide "basic" without any
extra effort, it makes sense to have that as default.
Also, in practice, I believe that in most situations you will have at
least one writer thread, therefore you will have to lock reads access
anyway,
Depending on the reader/writer ratio and frequency, you could be able
to use a non-broken reader-writer lock and increase the performance
tenfold or so on a sixteen core machine. :-)
so by this "basic" requirement you are pessimising quite useful
case for no gain.
Nope. It is you who decides to provide or not provide "basic", not me.
:-) To turn your example around, if another implementation of your
component interface has no internal cache, the user could be required
to lock around the read accesses for no reason.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]