|
Home > Archive > Unix Programming > January 2006 > threading in g++
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Hi, the gnu.g++ newsgroup is populated by trolling bots so I am posting
here. Can anyone tell me how gcc works with pthreads, as in using
shared memory and communication between threads? I assume (heh)
pthreads library is compiled with gcc, so this is a good place to ask
about this.
I am using freebsd. In C++ and C newsgroups I read about the keyword
sig_atomic_t, which is not related to threads according to the
standards but is reported to allow atomic operations depending on the
implementation. Can anyone shed some light on this?
| |
| Paul Pluzhnikov 2006-01-22, 6:11 pm |
| "Shark" <cpp_shark@yahoo.com> writes:
> Hi, the gnu.g++ newsgroup is populated by trolling bots
No, it isn't. There are plenty of posts from such bots (which are
ignored), but there are also human questions and answers.
> Can anyone tell me how gcc works with pthreads,
It works with them just as it does with any other external library.
> as in using
> shared memory and communication between threads?
Threads do not use "shared memory"; they run in the same memory space
(which is quite different).
> I assume (heh) pthreads library is compiled with gcc,
It probably is on freebsd, but that is completely irrelevant.
It could have been compiled with Intel 'icc', or any other compiler.
> I am using freebsd. In C++ and C newsgroups I read about the keyword
> sig_atomic_t, which is not related to threads according to the
> standards but is reported to allow atomic operations depending on the
> implementation. Can anyone shed some light on this?
What exactly is your question?
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
|
| I wrote a very simple/crude C++ wrapper for pthreads sometime
ago, If you are using C++ exclusively and don't want to get
into the nitty-gritty of pthreads I would suggest you use
that, it works on most platforms I've tried.
url:
http://www.partow.net/programming/p...pper/index.html
Arash Partow
________________________________________
________________
Be one who knows what they don't know,
Instead of being one who knows not what they don't know,
Thinking they know everything about all things.
http://www.partow.net
| |
|
| Paul Pluzhnikov wrote:
> "Shark" <cpp_shark@yahoo.com> writes:
>
>
> No, it isn't. There are plenty of posts from such bots (which are
> ignored), but there are also human questions and answers.
>
>
> It works with them just as it does with any other external library.
>
>
> Threads do not use "shared memory"; they run in the same memory space
> (which is quite different).
>
>
> It probably is on freebsd, but that is completely irrelevant.
> It could have been compiled with Intel 'icc', or any other compiler.
>
>
> What exactly is your question?
I just want to know if sig_atomic_t can be used for atomic thread
operations if we are using g++. C/C++ standards don't mention threads
at all, and threads are basically implementation-specific. If i declare
a global of type sig_atomic_t and compile the code with g++ and link
with pthreads under freebsd, is it guranteed that only one thread can
write to it at one time?
"Reading and writing this data type is guaranteed to happen in a single
instruction, so there's no way for a handler to run "in the middle" of
an access."
But it doesn't mention if the access is done through threads or not.
| |
| Paul Pluzhnikov 2006-01-22, 8:58 pm |
| "Shark" <cpp_shark@yahoo.com> writes:
> I just want to know if sig_atomic_t can be used for atomic thread
> operations if we are using g++.
What exactly do you mean by "atomic thread operations"?
> If i declare
> a global of type sig_atomic_t and compile the code with g++ and link
> with pthreads under freebsd, is it guranteed that only one thread can
> write to it at one time?
Not at all.
The type of variable has nothing to do with how many threads can
write to it at the same time. If you want to allow only one thread
to update a variable at a time, you must use proper synchronization
primitives, such as pthread_mutex_lock()/unlock().
> "Reading and writing this data type is guaranteed to happen in a single
> instruction, so there's no way for a handler to run "in the middle" of
> an access."
All this means for threads is that if the threads are doing this:
Thread1 Thread2 Thread3
while (1) while (1) while (1)
atomic_var = 0; atomic_var = ~0; other_atomic_var = atomic_var;
then other_atomic_var is going to either be 0 or ~0, but never
anything that is partially ~0 and partially 0 (e.g. 0x0000FFFF
or 0xFF00FF00 (assuming 32-bit system)).
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Ulrich Eckhardt 2006-01-23, 6:13 pm |
| Shark wrote:
> I am using freebsd. In C++ and C newsgroups I read about the keyword
> sig_atomic_t, which is not related to threads according to the
> standards but is reported to allow atomic operations depending on the
> implementation.
Well, I think you should reread what you read there. ;)
the 'sig' means that it is atomic with respect to signals, not threads.
If you really have a problem with GCC, this is the group or the one next
door for the C++ compiler. If the problem is with threaded programming,
there is comp.programming.threads. If you need advise on a higher level
concerning a unixoid system, c.u.p is right. Other than that, I also don't
get what your problem is, sorry.
Uli
--
http://gcc.gnu.org/faq.html
| |
| Hannah Schroeter 2006-01-23, 8:49 pm |
| Hello!
Shark <cpp_shark@yahoo.com> wrote:
>Hi, the gnu.g++ newsgroup is populated by trolling bots so I am posting
>here. Can anyone tell me how gcc works with pthreads, as in using
>shared memory and communication between threads? I assume (heh)
>pthreads library is compiled with gcc, so this is a good place to ask
>about this.
>I am using freebsd. In C++ and C newsgroups I read about the keyword
>sig_atomic_t, which is not related to threads according to the
>standards but is reported to allow atomic operations depending on the
>implementation. Can anyone shed some light on this?
Usually you use something like -pthread both for compiling and linking
to compile your programs with pthread support. Then you can use the
interfaces defined in <pthread.h>, see apropos pthread.
sig_atomic_t is IIRC an integer type where you can atomically assign
or read a variable of type volatile sig_atomic_t. It does no magic
besides that. Especially it doesn't mean that foo++ is an atomic
increment for a volatile sig_atomic_t foo.
I sometimes used sig_atomic_t for signal handlers, like
volatile sig_atomic_t signal_called = 0;
void sighandler(int signum)
{
signal_called = 1;
}
In main program, use signal_called to do the real action for the
signal. Needed if you want signal-triggered actions to do more than
what's allowed in signal handlers directly. Either you use a timeout
to periodically check signal_called, or you use pselect to make sure
that there's only definite points where the signal is delivered,
or you use the self-pipe trick, if you want to avoid races that can
cause handling to be delayed for too long.
I.e. sig_atomic_t doesn't mean all too much with respect to threads.
For mutual exclusion, use pthread_mutex_t and the appropriate
pthreads functions, or the semaphore functions from <semaphore.h>.
For other coordination, things like condition variables or read-write
locks may also be useful, also all available from <pthread.h>.
If you have an efficient pthread implementation, mutexes shouldn't
be that slow (usually implemented by a machine dependent atomic-exchange
or atomic-increment instruction, a fast path for the case of no
contention, and putting the thread to sleep in case the lock is already
held; releasing the lock is something like unsetting the variable and
signalling potential waiting threads to wakeup; the reality is a little
bit more complicated, but that's the general gist).
Kind regards,
Hannah.
|
|
|
|
|