This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: question about race:stream in glibc manual

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]