Hi folks,

I have a question about the data-race-freedom of
`std::ios_base::xalloc'.

`std::ios_base::xalloc' has to read and modify an internal counter
object that is shared among threads. So, the implementation has to
synchronize the operations on the counter object, otherwise it may
introduce data races.

I believe that the standard wording implicitly specifies `xalloc' is
free from data races, because the internally used shared counter
object "is not visible to users and is protected against data
races" (quoted from 17.6.5.9/7).

However, `std::ios_base::index' is declared to be `static int' (marked
with "exposition only") in 27.5.3 (`std::ios_base' definition), and
27.5.3.5/1 says that `xalloc' returns `index++'. Therefore,
straightforward reading of these paragraphs falls into the conclusion
that concurrent invocations of `xalloc' may introduce data races.

Which is the intent of the standard, then?

If the former interpretation (i.e., `xalloc' is free from data races)
is the intent of the standard, some editorial modifications (e.g.,
declaring `std::ios_base::index' to be `static std::atomic_int'
instead of `static int' in 27.5.3) would make the wording much
clearer.

I would like to hear from experts. Thank you in advance for your help.


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Am 24.06.2012 09:03, schrieb Ai Azuma:
>
> Hi folks,
>
> I have a question about the data-race-freedom of
> `std::ios_base::xalloc'.
>
> `std::ios_base::xalloc' has to read and modify an internal counter
> object that is shared among threads. So, the implementation has to
> synchronize the operations on the counter object, otherwise it may
> introduce data races.
>
> I believe that the standard wording implicitly specifies `xalloc' is
> free from data races, because the internally used shared counter
> object "is not visible to users and is protected against data
> races" (quoted from 17.6.5.9/7).
>
> However, `std::ios_base::index' is declared to be `static int' (marked
> with "exposition only") in 27.5.3 (`std::ios_base' definition), and
> 27.5.3.5/1 says that `xalloc' returns `index++'. Therefore,
> straightforward reading of these paragraphs falls into the conclusion
> that concurrent invocations of `xalloc' may introduce data races.


I agree with your analysis that the current specification may
introduce data races. There already exists a library issue submission
request (LWG 2143 "ios_base::xalloc should be thread-safe") not yet
visible in the official list.

> Which is the intent of the standard, then?
>
> If the former interpretation (i.e., `xalloc' is free from data races)
> is the intent of the standard, some editorial modifications (e.g.,
> declaring `std::ios_base::index' to be `static std::atomic_int'
> instead of `static int' in 27.5.3) would make the wording much
> clearer.
>
> I would like to hear from experts. Thank you in advance for your help.


I think we miss normative wording that provides the necessary
guarantee. We better should add explicit normative wording to that
effect, IMO.

HTH & Greetings from Bremen,

Daniel Kr   gler




--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 6   25   ,       3:48, Daniel Kr  gler<daniel.krueg...@googlemail.com>
wrote:
>  I agree with your analysis that the current specification may
>  introduce data races. There already exists a library issue submission
>  request (LWG 2143 "ios_base::xalloc should be thread-safe") not yet
>  visible in the official list.

Oops! I should have intensively watched the up-to-date draft of LWG
issue list.

>  I think we miss normative wording that provides the necessary
>  guarantee. We better should add explicit normative wording to that
>  effect, IMO.

The proposed wording of LWG 2143 looks fine to me.

Thanks anyway for your clarification, Daniel.


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]