[627] in Pthreads mailing list archive
question on implementation of _r functions
daemon@ATHENA.MIT.EDU (Cheryl Huntington)
Thu Apr 10 22:07:51 1997
Date: Thu, 10 Apr 1997 18:56:28 -0700
From: Cheryl Huntington <clh@swdc.stratus.com>
To: pthreads@MIT.EDU
Cc: Cheryl Huntington <clh@swdc.stratus.com>,
Roy Lemmon <rlem@swdc.stratus.com>
Hi all,
I'm confused on the implementation of the "_r" functions. I'll use
readdir() and readdir_r() as an example. They both protect data with
mutexes, then call readdir_basic(). For easy reference, I've included
the code for them below.
My first question is whether the mutexes are necessary for readdir(). I
was assuming that the existing functions did not need to be changed, and
would have done something like
readdir()
{ no changes }
readdir_r(...)
{
char *bp;
mutex lock;
bp = readdir();
copy from bp to result;
mutex unlock;
}
The disadvantage to this may be performance because the mutex is held
locked for the full readdir() call, but that's what both readdir() and
readdir_r() do now. With my way the performance of readdir() is not
affected. But is it legit?
The Solaris man page says that readdir() is not thread safe and that
readdir_r() should be used in multithreaded applications.
Other examples are asctime() and asctime_r(), where asctime() is made
thread-safe with thread specific data, then returns the results from
asctime_r(). Why use thread-specific data? And, the data manipulation in
asctime_r is not protected by mutexes, which I would expect.
My last example is gethostent() and gethostent_r(). In this case,
gethostent() creates a buffer, then calls gethostent_r(), which proceeds
to do the work protected by mutexes. I would have done this like my
readdir() example above.
gethostent_r()
{
struct hostent *hp;
mutex lock;
hp = gethostent();
copy from hp to result;
mutex unlock;
}
Am I missing some basic threads concept here? I think proven's code
will work, I'm just wondering if it's necessary.
Cheryl
--
Cheryl Huntington clh@swdc.stratus.com 408-559-5665
Stratus Western Development Center, Commands and Utilities Group
