vfscanf in newlib
Sat Apr 21 17:11:00 GMT 2001
----- Original Message -----
From: "Christopher Faylor" <firstname.lastname@example.org>
Sent: Sunday, April 22, 2001 9:25 AM
Subject: Re: vfscanf in newlib
> On Sat, Apr 21, 2001 at 01:38:58PM -0400, Charles S. Wilson wrote:
> >Didn't somebody already do a threadsafeness audit of newlib? If so,
> >then we don't want to break threadsafeness with these changes. I'm
> >familiar with threaded code in C; what is neccessary to insure that a
> >given function is both reentrant and threadsafe (if a block of code
> >threadsafe it is automatically reentrant, but a reentrant block is
> >necessarily threadsafe, right?)
Correct. re-entrant code does not uses passed parameters, read-only data
and local-nonstatic variables only. Any exceptions to that list are
protected by mutex's/critical sections and the like. Essentially calling
the same function while another process or thread is paused within it
won't cause problems. Threadsafe adds the requirement that concurrent
processing of the code (say on two threads executing on two processors)
will not cause problems. This generally involves syncronising all access
to non-local variables (in addition to the reentrant requirements).
(Syncronisation can be as simple as using InterLockedExchange when
adding to a list, or as complex as mutex and condition vars with
trylock()s and more.)
> That's right.
> AFAIK, newlib is not guaranteed to be thread safe.
> So, I guess that Cygwin is, by extension, not really thread safe
> I can think of a few functions in cygwin that are not thread safe, in
> fact. The enviroment manipulation is not thread-safe. I don't
> that vfork is thread safe. I'm sure that there are many others.
Well the SUS doesn't require libc to be thread-safe. It only requires
the thread-safe functions (not all of which are named _r) to be
threadsafe. IMO we should only introduce _r versions of functions when t
hey are thread-safe.
More information about the Newlib