This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: Is the standard IO library thread safe?
- To: glibc-linux AT ricardo.ecn.wfu dot edu
- Subject: Re: Is the standard IO library thread safe?
- From: Kaz Kylheku <kaz AT ashi.footprints dot net>
- Date: Fri, 17 Sep 1999 09:30:54 -0700 (PDT)
- Reply-To: glibc-linux AT ricardo.ecn.wfu dot edu
On Fri, 17 Sep 1999, Luc Andre wrote:
> > flockfile(file);
> > putc_locked('a', file);
> > pubc_locked('b', file);
> > putc_locked('c', file); /* error checking omitted */
> > funlockfile(file);
> >
> >If all other uses of file use correct locking, the above should
> >write "abc" to the stream.
>
> If 'file' is locked by flockfile(file); why do we need to lock it again using
> putc_locked ? I always though that I could directly use putc for a locked
> file.
Oops, you are right. I get mixed up with the backwards terminology of the
new thread safe stdio functions! The name _locked seems to imply that the
object is already assumed locked and so no locks are necessary. I use that
naming scheme myself and have seen it in other people's software projects:
that is to say, the ``regular'' interface methods of the object that do
the locking have no suffix, and the unsafe ones are called ``_unlocked''
or something to that effect. But POSIX has the opposite meaning for
``_unlocked'', meaning that the operation doesn't use a lock.
In the example, I should have just used putc_unlocked, or just
putc.