This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: question about race:stream in glibc manual
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: MaShimiao <mashimiao dot fnst at cn dot fujitsu dot com>, carlos at systemhalted dot org, Alexandre Oliva <aoliva at redhat dot com>
- Cc: libc-help at sourceware dot org
- Date: Tue, 18 Nov 2014 11:34:57 -0500
- Subject: Re: question about race:stream in glibc manual
- Authentication-results: sourceware.org; auth=none
- References: <54654BA4 dot 7020702 at cn dot fujitsu dot com>
On 11/13/2014 07:24 PM, MaShimiao wrote:
> Hi Carlos, Alexandre
>
> I'm Ma Shimiao. I'm a bit new to glibc. I have a question about glibc
> manual, could you help me?
>
> The glib manual says, if a function annotated with race, it should
> operate on objects in ways that may cause data races or similar forms
> of destructive interference out of concurrent execution. In some
> cases, the objects are passed to the functions by users; in others,
> they are used by the functions to return values to users; in others,
> they are not even exposed to users. We consider access to objects
> passed as (indirect) arguments to functions to be data race free. The
> assurance of data race free objects is the callerâs responsibility.
> We will not mark a function as MT-Unsafe or AS-Unsafe if it
> misbehaves when users fail to take the measures required by POSIX to
> avoid data races when dealing with such objects.
>
> According to the manual, I think if a function has an argument FILE
> *stream and the stream may cause data races inside the function, it
> should annotated with MT-Safe race:stream. Am I right?
You are not correct. The FILE* is an opaque object.
The user has no control over the internals of the
opaque object and the contents are modified by the
implementation and not known to the user. Therefore
the user can expect the implementation to be thread
safe and it is up to the implementation to do whatever
locking is required to make it work.
As an optimization there are *_unlocked function
variants that are not thread safe, and those *are*
marked with "race:stream", but only those.
Cheers,
Carlos.