Re: Linux Threading
From: Grant Edwards (grante_at_visi.com)
Date: 10/06/05
- Next message: Nitin: "kernel compile error"
- Previous message: Peter T. Breuer: "Re: Linux Threading"
- In reply to: Peter T. Breuer: "Re: Linux Threading"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 06 Oct 2005 17:48:30 -0000
On 2005-10-06, Peter T. Breuer <ptb@oboe.it.uc3m.es> wrote:
>>> Can I move them around across thread boundaries?
>
>> I'm not sure what you mean by "move them" or "thread boundaries".
>
> I'm not sure either. But I wuld guess that instead of the
> socket bind listen accept cycle on one thread, he wants to
> signal a second thread to take over after the listen or the
> accept.
>
> That would imply that the socket were already shared via the
> descriptor, which is the case anyway if the threads (even
> processes) split after its creation. I'm not at all sure what
> would happen if one created the socket in one thread, getting
> its descriptor and then thread to get a second thread to use
> that same descriptor.
No problem. It doesn't matter whether the thread was created
before or after the file/socket was opened.
> .. well, since the descriptors are just
> indexes into a table _io of structs, I suppose the question is
> if the _io table is shared, to which I would say "yes".
Everything in memory is shared between threads.
> What about the structs in that table ... hmmm. Shared as well.
Yup.
> What if they are addresses pointing somewhere else? Shared as
> well. The memory address space is shared between threads.
Yup.
> So mental thought experiment gives a positive answer.
Exactly.
>>> Can I share them (guarding of course with a mutex of course),
>>> across multiple threads?
>
>> Sure. I don't think you need a mutex.
>
> Well, he needs to signal somehow.
Maybe not. If the file descriptor is passed to the thread upon
creation, you could get by with no additional signalling.
> A mutex has the advantage of also protecting against
> confusions.
Only if you need mutual exclusion.
>> I don't know if operations on a single FILE pointer are thread
>> safe or not.
>
> Reasoning says that they ought to be, since the buffers reside
> in user space, and hence will be shared between threads.
They're definitly shared, but whether operations on them are
thread-safe depends on the structure of the user-space
functions and macros (e.g. fread/fwrite/fputc/fgetc) that
manipulate them.
The last time I looked at macros like putchar() and getchar(),
they were definitely not thread safe. However, that was a
long, long time ago. The current man pages indicate that the
"standard" versions of those are thread safe, and if you want
the old versions you append _unlocked to the name:
$ man unlocked_stdio
UNLOCKED_STDIO(3) Linux Programmer's Manual UNLOCKED_STDIO(3)
NAME
*_unlocked - non-locking stdio functions
SYNOPSIS
#include <stdio.h>
int getc_unlocked(FILE *stream);
int getchar_unlocked(void);
int putc_unlocked(int c, FILE *stream);
[...]
DESCRIPTION
Each of these functions has the same behaviour as its counterpart with-
out the `_unlocked' suffix, except that they do not use locking (they
do not set locks themselves, and do not test for the presence of locks
set by others) and hence are thread-unsafe. See flockfile(3).
CONFORMING TO
The four functions getc_unlocked(), getchar_unlocked(),
putc_unlocked(), putchar_unlocked() are in POSIX.1. The nonstandard
*_unlocked() variants occur on a few Unix systems, and are available in
recent glibc. They should probably not be used.
SEE ALSO
flockfile(3)
2001-10-18 UNLOCKED_STDIO(3)
--
Grant Edwards grante Yow! I hope something GOOD
at came in the mail today so
visi.com I have a REASON to live!!
- Next message: Nitin: "kernel compile error"
- Previous message: Peter T. Breuer: "Re: Linux Threading"
- In reply to: Peter T. Breuer: "Re: Linux Threading"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
