Mario Charest <mcharest@nozinformatic.com> wrote:
On 20 Apr 2001 14:52:03 GMT, Wojtek Lerch <> wojtek@qnx.com> > wrote:
But there’s another thing… Hey, isn’t that what you originally meant:
since QNX4 “threads” are really separate processes that share their data
space, a file descriptor is only meaningful to the thread that opened
it, and to its children. If one thread calls fopen() and then another
thread calls fprintf() on the same FILE, the fd that the FILE is using
might be invalid in the other thread – or refer to a completely
different file. Even though you don’t crash in fprintf (because the
consistency of the contents of the FILE structure is protected by the
semaphore), printf() may either fail or write to the wrong file.
No I don’t think that’s the case, although I’m now very confused > 
I see it on two levels. I’ll use a link list as an example.
However since those functions don’t make use of global variable they
can be use in two differents threads simulatenously if they are not
working on the same list.
It would be innefficient to have a single semaphore to protect the
link list function. In the case of each thread working on different
list there is no point in protected them, worse if this would be
running on SMP, it would be real bad. Hence what needs to be
protected is the DATA, so each list should have its OWN semaphore.
Watcom seems to use a single semaphore for all your FILEs. I just ran a
test case where each thread opens /dev/tty and calls fgets() – and one
thread ended up reply-blocked on Dev while all the other threads were
semaphore-blocked.
But that’s not how POSIX wants it to work – POSIX wants each FILE to
have its own lock, implemented with flockfile(), and requires that it
should be safe for multiple threads to give the same FILE to fprintf()
or other functions at the same time.
According to the doc memcpy is thread safe. If you memcpy to the same
destination in two different threads, the end result might be
corrupted data. Hence some level of protection at a higher level
Yes… It seems that memcpy() doesn’t really fit into the definition
that I cited, does it…
I don’t have a copy of POSIX here, but according to
http://www.UNIX-systems.org/whitepapers/reentrant.html:
In POSIX.1c, a “reentrant function” is defined as a “function whose
effect, when called by two or more threads, is guaranteed to be as
if the threads each executed the function one after another in an
undefined order, even if the actual execution is interleaved”
(ISO/IEC 9945:1-1996, 2.2.2).
is required. That how I understood fprintf before you indicated
it was protected by a semaphore. I though fprintf was thread-safe
(meaning you can have multiple fprintf happening) but not if
you use the same file descriptor, since the FILE structure don’t
appear to have its own semaphores.
Well, printf() is supposed to be thread-safe, too.
If all buffered filebase functions have the SAME semaphores,
then I think that’s not really good for performance as an fprintf on a
file could get block/delayed by a getc on the keyboard. On
a single CPU that’s probably not critical but on SMP that
could be desastrous, but we don’t have to worry about that
with QNX4 >
If you have an application where one thread does
puts( “Press Enter to interrupt” );
getchar();
kill_all_threads();
while other threads are trying to process some files, having the
getchar() share the semaphore with all the other files would be pretty
bad even on a single CPU.
So from what you are saying it has more to do with “file locking”
issues then threads.
You mean the kind of file locking that fcntl(F_SETLK) implements?
No, I put “file locking” in quote because I couldn’t find a better
word. The right word ( it just came to me) is synchronisation.
POSIX calls it “stream locking”. And, of course, it does have to do
with threads.
–
Wojtek Lerch (wojtek@qnx.com) QNX Software Systems Ltd.