http://groups.google.com/group/comp.programming.threads?hl=en
comp.programming.threads@googlegroups.com
Today's topics:
* Should pthread_exit() be used in main()? - 3 messages, 2 authors
http://groups.google.com/group/comp.programming.threads/t/6f5af4a14c06e2b3?hl=en
* Could This Be REAL? Watch This! - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/9511871bb9ec2f0c?hl=en
* possible problem with pthread mutexes, looking for opinions - 6 messages, 2
authors
http://groups.google.com/group/comp.programming.threads/t/de9d97d417bb51f2?hl=en
* Welcome to our site: www.ec21baba.com we are a leading company in dealing
with brand shoes - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/4d09ad70ae294d71?hl=en
==============================================================================
TOPIC: Should pthread_exit() be used in main()?
http://groups.google.com/group/comp.programming.threads/t/6f5af4a14c06e2b3?hl=en
==============================================================================
== 1 of 3 ==
Date: Tues, Jun 2 2009 9:18 pm
From: Sunnz
Hi,
I just started learning pthreads, and are little confused with
pthread_exit(), namely, when should it be used?
I have written very basic codes to try to understand how it works:
http://pastebin.com/m79438632
Here if you comment out pthread_exit() in main(), all the child threads
don't get to finish, unless you uncomment the for loop that joins all
child threads.
So does pthread_exit() does that for you? That the process and its
threads doesn't get killed till all threads has 'finished'?
Should PrintHello in the above example call pthread_exit()?
== 2 of 3 ==
Date: Wed, Jun 3 2009 3:18 am
From: Dave Butenhof
Sunnz wrote:
> Hi,
>
> I just started learning pthreads, and are little confused with
> pthread_exit(), namely, when should it be used?
>
> I have written very basic codes to try to understand how it works:
> http://pastebin.com/m79438632
>
> Here if you comment out pthread_exit() in main(), all the child threads
> don't get to finish, unless you uncomment the for loop that joins all
> child threads.
>
> So does pthread_exit() does that for you? That the process and its
> threads doesn't get killed till all threads has 'finished'?
>
> Should PrintHello in the above example call pthread_exit()?
pthread_exit() causes the calling thread to terminate; just as calling
exit() causes the process to terminate.
Just as a process returning from main() implicitly calls exit(), most
threads implicitly call pthread_exit() on return from the thread start
routine. The exception is the initial thread, the one running main();
because if we had changed that behavior it would have affected existing
non-threaded programs as well.
So if you want the initial process thread to terminate, leaving other
threads in the process to continue operation, you need to explicitly
call pthread_exit() rather than returning from main().
Aside from that, if your application architecture is such that it makes
sense to cause the current thread to terminate other than by returning
from the start routine, call pthread_exit(). If not... don't worry about it.
Specifically; in the example you cite, the pthread_exit() call from
PrintHello(), which is the thread start routine, is redundant; it could
just as easily have simply returned with the value NULL.
In main(), however, with the pthread_join() calls commented out, you do
need the pthread_exit() to ensure that the PrintHello() threads are
allowed to finish before the process evaporates. The process will go
away automatically when the last thread terminates; but you have no
control over the process exit status in this case. If you care about the
process exit status, you should use pthread_join() to ensure that all
your threads have created, and then either return from main() or call
exit() with the desired exit status.
However, main(), except for the call stack arrangement that happens to
lead to the implicit exit() call on return, is no different from any
other thread. If you want 4 threads each running PrintHello(), and you
have nothing in particular for the initial thread to do after launching
other threads, you might as well make IT one of those 4 by simply making
(NUM_THREADS - 1) calls to pthread_create(), and then calling
PrintHello() with an appropriate argument. When the call returns to
main(), it can wait for the other threads to finish and exit, or simply
call pthread_exit() to let the process terminate passively when the last
is done. This performs the same job with less overhead. (Not that the
overhead of thread creation is important in this trivial I/O bound example.)
== 3 of 3 ==
Date: Wed, Jun 3 2009 4:53 am
From: Sunnz
Dave Butenhof 提到:
>
> Aside from that, if your application architecture is such that it makes
> sense to cause the current thread to terminate other than by returning
> from the start routine, call pthread_exit(). If not... don't worry about
> it.
>
> Specifically; in the example you cite, the pthread_exit() call from
> PrintHello(), which is the thread start routine, is redundant; it could
> just as easily have simply returned with the value NULL.
>
Right, so if "return NULL" was written in PrintHello() instead of
pthread_exit(), then it will implicitly call pthread_exit()?
So what actually would happen here when it calls pthread_exit() but
doesn't have a return? Would it simply terminate the thread without
returning anything? If so would it make more sense for start routines
that doesn't return anything?
> However, main(), except for the call stack arrangement that happens to
> lead to the implicit exit() call on return, is no different from any
> other thread. If you want 4 threads each running PrintHello(), and you
> have nothing in particular for the initial thread to do after launching
> other threads, you might as well make IT one of those 4 by simply making
> (NUM_THREADS - 1) calls to pthread_create(), and then calling
> PrintHello() with an appropriate argument. When the call returns to
> main(), it can wait for the other threads to finish and exit, or simply
> call pthread_exit() to let the process terminate passively when the last
> is done. This performs the same job with less overhead. (Not that the
> overhead of thread creation is important in this trivial I/O bound
> example.)
Thanks a lot for the clear explanation and the tips it surely helps a
lot for beginners like me!! :D
==============================================================================
TOPIC: Could This Be REAL? Watch This!
http://groups.google.com/group/comp.programming.threads/t/9511871bb9ec2f0c?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Jun 3 2009 11:22 am
From: B-doe
A man showing how he personally makes 2.6m in 9 months! Could this be
Real? He's also revealing the secrets to you! Would you like to learn
how?
Life Changing Opportunity = http://tinyurl.com/nj8ltg
100% Guaranteed!
==============================================================================
TOPIC: possible problem with pthread mutexes, looking for opinions
http://groups.google.com/group/comp.programming.threads/t/de9d97d417bb51f2?hl=en
==============================================================================
== 1 of 6 ==
Date: Wed, Jun 3 2009 4:00 pm
From: Chris Friesen
I've received reports of code failing, and I wanted to make sure that I
wasn't missing something.
1)We have instrumented code of the following form:
lock_wrapper:
pthread_mutex_lock()
if the lock succeeded
lockcounter++
else
fail noisily
unlock_wrapper:
unlockcounter++
if (unlockcounter != lockcounter)
assert(0)
pthread_mutex_unlock()
I can think of three ways for the assertion to happen: 1) a thread that
isn't the owner is calling the unlock wrapper, or 2) there is a
compiler/pthread bug such that another thread is calling lock_wrapper
and the lockcounter increment is being hoisted before the lock, 3) the
underlying lock implementation is buggy.
Did I miss anything?
2) We have code that does the usual
pthread_mutex_lock()
...do stuff..
pthread_mutex_unlock()
and the unlock is occasionally failing with EPERM. Assuming that we're
not doing any locking from signal handlers, and that the lock call
succeeded, is there any other explanation other than a
pthread/compiler/kernel bug?
Thanks,
Chris
== 2 of 6 ==
Date: Wed, Jun 3 2009 4:58 pm
From: "Chris M. Thomasson"
"Chris Friesen" <cbf123@mail.usask.ca> wrote in message
news:gM6dneXMtegenbrXnZ2dnUVZ_uudnZ2d@posted.sasktel...
> I've received reports of code failing, and I wanted to make sure that I
> wasn't missing something.
>
>
> 1)We have instrumented code of the following form:
>
> lock_wrapper:
> pthread_mutex_lock()
> if the lock succeeded
> lockcounter++
> else
> fail noisily
>
> unlock_wrapper:
> unlockcounter++
> if (unlockcounter != lockcounter)
> assert(0)
> pthread_mutex_unlock()
>
>
> I can think of three ways for the assertion to happen: 1) a thread that
> isn't the owner is calling the unlock wrapper,
Perhaps. That would be a buggy application, and not PThreads fault. Have you
inserted a breakpoint at the assertion and examined the state of the
applications threads?
> or 2) there is a
> compiler/pthread bug such that another thread is calling lock_wrapper
> and the lockcounter increment is being hoisted before the lock
Well, shi% does happen:
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/63f6360d939612b3
Ouch!
> , 3) the
> underlying lock implementation is buggy.
>
> Did I miss anything?
When you write `fail noisily', what do you mean exactly? Are you calling
`abort()'? Has this ever happened? If so, what error code is it `EINVAL',
`EAGAIN' or perhaps `EDEADLK'? Are you using recursive and/or error checking
mutexs?
> 2) We have code that does the usual
>
> pthread_mutex_lock()
> ...do stuff..
> pthread_mutex_unlock()
>
> and the unlock is occasionally failing with EPERM.
That's a buggy application.
> Assuming that we're
> not doing any locking from signal handlers, and that the lock call
> succeeded, is there any other explanation other than a
> pthread/compiler/kernel bug?
Bugs in user application.
== 3 of 6 ==
Date: Wed, Jun 3 2009 5:30 pm
From: Chris Friesen
Chris M. Thomasson wrote:
> "Chris Friesen" <cbf123@mail.usask.ca> wrote in message
> news:gM6dneXMtegenbrXnZ2dnUVZ_uudnZ2d@posted.sasktel...
>>1)We have instrumented code of the following form:
>>
>>lock_wrapper:
>>pthread_mutex_lock()
>>if the lock succeeded
>>lockcounter++
>>else
>>fail noisily
>>I can think of three ways for the assertion to happen: 1) a thread that
>>isn't the owner is calling the unlock wrapper,
> Perhaps. That would be a buggy application, and not PThreads fault. Have you
> inserted a breakpoint at the assertion and examined the state of the
> applications threads?
I'm not directly involved in the testing. I haven't suggested manually
examining the state, but since they've already got a wrapper I suggested
tracking the owner themselves in the wrapper.
>>, 3) the
>>underlying lock implementation is buggy.
>>
>>Did I miss anything?
> When you write `fail noisily', what do you mean exactly?
If pthread_mutex_lock() returns nonzero, the wrapper calls assert(0).
In the error path that is being seen, this assertion is not being hit
but the one in the unlock case is.
> Are you using recursive and/or error checking
> mutexs?
No, the comparison of the unlock and lock counts is done only for
regular mutexes.
>>2) We have code that does the usual
>>
>>pthread_mutex_lock()
>>...do stuff..
>>pthread_mutex_unlock()
>>
>>and the unlock is occasionally failing with EPERM.
>
>
> That's a buggy application.
That's a bit harsh. It's possible (though maybe not likely) that a flaw
in the underlying locking implementation could cause this.
This following URL describes an assertion failing in
pthread_mutex_lock() because of a gcc compiler bug. A similar bug could
conceivably cause problems in pthread_mutex_unlock().
http://sourceware.org/bugzilla/show_bug.cgi?id=3328
Also, in this particular case the application is using C++. There is an
automatic variable in a particular scope. The mutex is passed to the
constructer, is locked in the constructor and unlocked in the
destructor. I've asked if there is any other places where that mutex is
locked/unlocked, and also whether the program aborts if the lock fails.
Chris
== 4 of 6 ==
Date: Wed, Jun 3 2009 6:39 pm
From: "Chris M. Thomasson"
"Chris Friesen" <cbf123@mail.usask.ca> wrote in message
news:KrudnVt7NpEFiLrXnZ2dnUVZ_tCdnZ2d@posted.sasktel...
> Chris M. Thomasson wrote:
>> "Chris Friesen" <cbf123@mail.usask.ca> wrote in message
>> news:gM6dneXMtegenbrXnZ2dnUVZ_uudnZ2d@posted.sasktel...
>
>>>1)We have instrumented code of the following form:
>>>
>>>lock_wrapper:
>>>pthread_mutex_lock()
>>>if the lock succeeded
>>>lockcounter++
>>>else
>>>fail noisily
>
>
>>>I can think of three ways for the assertion to happen: 1) a thread that
>>>isn't the owner is calling the unlock wrapper,
>
>> Perhaps. That would be a buggy application, and not PThreads fault. Have
>> you
>> inserted a breakpoint at the assertion and examined the state of the
>> applications threads?
>
> I'm not directly involved in the testing. I haven't suggested manually
> examining the state, but since they've already got a wrapper I suggested
> tracking the owner themselves in the wrapper.
That should help...
>>>2) We have code that does the usual
>>>
>>>pthread_mutex_lock()
>>>...do stuff..
>>>pthread_mutex_unlock()
>>>
>>>and the unlock is occasionally failing with EPERM.
>>
>>
>> That's a buggy application.
>
> That's a bit harsh. It's possible (though maybe not likely) that a flaw
> in the underlying locking implementation could cause this.
Well, it's a habit of mine to automatically assume that it must be a bug in
my application instead of casting doubt on the underlying native
implementation. It very well may be a bug in the impl, but I have my doubts
because you say that the assertion sometimes hit on the `unlockcounter' not
being equal to the `lockcounter' which means that either the counters are
not being confined within the critical-section, or the application is
bugged.
> This following URL describes an assertion failing in
> pthread_mutex_lock() because of a gcc compiler bug. A similar bug could
> conceivably cause problems in pthread_mutex_unlock().
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=3328
Have you tried dissembling the compiled code and validating that the
counters are being confined and/or replacing the PThread mutex with a custom
one and seeing if you can reproduce the problem? How about creating an
isolated test case and see if suffers from the assertion on
`pthread_mutex_unlock()'? How about trying to use atomic fetch-and-add to
mutate the `lockcounter'? What about manually inserting a compiler barrier
before each counter update?
> Also, in this particular case the application is using C++. There is an
> automatic variable in a particular scope. The mutex is passed to the
> constructer, is locked in the constructor and unlocked in the
> destructor. I've asked if there is any other places where that mutex is
> locked/unlocked, and also whether the program aborts if the lock fails.
Please try the following simple program I just quickly coded up and see if
anything asserts:
http://cpt.pastebin.com/f2f632b93
If your getting `counter out of sync!' error, well, if your on an IA-32, you
can try to replace the mutations of `mutex::m_count' with fetch-and-add:
______________________________________________________________________
typedef char static_assert[
sizeof(unsigned) == 32 / CHAR_BIT ? 1 : -1
];
__attribute__((always_inline))
static __inline__
unsigned
atomic_ia32_faa32(
unsigned volatile* self,
unsigned const addend
) {
unsigned ret;
__asm__ __volatile__(
"LOCK XADDL %2, %1;\n"
: "=&r" (ret),
"=m" (*self)
: "0" (addend)
: "memory",
"cc"
);
return ret;
}
______________________________________________________________________
Any thoughts?
== 5 of 6 ==
Date: Wed, Jun 3 2009 6:40 pm
From: "Chris M. Thomasson"
BTW, what platform and architecture is this application failing under?
== 6 of 6 ==
Date: Wed, Jun 3 2009 8:17 pm
From: "Chris M. Thomasson"
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:YAFVl.2127$GD4.73@newsfe15.iad...
> [...]
>
> Please try the following simple program I just quickly coded up and see if
> anything asserts:
>
> http://cpt.pastebin.com/f2f632b93
Using the *nasty* `union thread_id' hack aside for a moment, I make small
dyslexic mistake in a call to `UNEXPECTED()'. The code in question is in the
`mutex::unlock()' procedure:
________________________________________________________________________
void unlock() {
if (! (m_count % 2)) {
UNEXPECTED(("`mutex::unlock()' counter out of sync!"));
}
thread_id self;
self.tid = pthread_self();
if (! pthread_equal(m_owner.tid, self.tid)) {
UNEXPECTED(("`mutex::unlock()' thread(%u) is NOT owner! thread(%u)
is!",
m_owner.id, self.id));
}
++m_count;
#if ! defined (NDEBUG)
thread_id dbg_temp_id = m_owner;
unsigned dbg_temp_count = m_count;
No comments:
Post a Comment