Re: pthread_join
Re: pthread_join
- Subject: Re: pthread_join
- From: Marc Van Olmen <email@hidden>
- Date: Sat, 11 Sep 2004 13:33:11 -0400
- Resent-date: Sun, 12 Sep 2004 15:17:04 -0400
- Resent-from: Marc Van Olmen <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: email@hidden
HI,
I can confirm that when I call pthread_detach at the end of the
function entry there is no leak any more in the virtual memory space.
I'm still surprised that I need to call pthread_detach myself at the
end of function call, because couldn't find any remark of that in the
book, and threads under OS X seems to be created by default in 'attach'
mode.
thanks for you time again,
mvo
ps: so my function looks like this (with the 2 options):
one remark: The detach-thread version with semaphore techniques uses
less memory then the 'attach'-thread and pthread_join technique.
void* cOS_Thread::Entry(cOS_Thread* inCAPThread)
{
int anError;
void* theAnswer = NULL;
if(inCAPThread->mThreadRoutine != NULL)
{
#if FW_SEMAPHORE_WAIT_TECHNIQUE
inCAPThread->mWaitSemaphore->Lock();
#endif
theAnswer =
inCAPThread->mThreadRoutine(inCAPThread->mThreadParameter);
#if FW_SEMAPHORE_WAIT_TECHNIQUE
inCAPThread->mThreadFinished = true;
inCAPThread->mWaitSemaphore->Notify();
inCAPThread->mWaitSemaphore->Unlock();
#else
anError = pthread_detach(inCAPThread->mPThread);
OS_ThrowIf(anError != 0, anError, "cOS_Thread::Entry: Could not
detach the thread");
#endif
}
inCAPThread->mPThread = 0;
return theAnswer;
}
On Sep 11, 2004, at 12:16 PM, Marc Van Olmen wrote:
Hi Paul
Thanks for you reaction:
On Sep 11, 2004, at 1:00 AM,
email@hidden wrote:
You are leaking threads. You need to either detach or join them.
If you are comparing how the two options perform, it may be better to
not use the semaphore at all in the attached case and simply join the
thread.
You are right here, in case of attached i don't use Semaphore
technique.
I gonna do some more testing with your hint about "detach"
Also wanted to give one remark is that I'm doing QuickTime calls (but
i use the EnterMoviesOnThread and Exit.... calls....
I also wanted to give one correction to my the code (and also matt
code) I'm just doing this for the record so people that search
archive:
void* cOS_Thread::Entry(cOS_Thread* inCAPThread)
{
void* theAnswer = NULL;
if(inCAPThread->mThreadRoutine != NULL)
{
#if FW_SEMAPHORE_WAIT_TECHNIQUE
inCAPThread->mWaitSemaphore->Lock();
#endif
theAnswer =
inCAPThread->mThreadRoutine(inCAPThread->mThreadParameter);
#if FW_SEMAPHORE_WAIT_TECHNIQUE
inCAPThread->mThreadFinished = true;
inCAPThread->mWaitSemaphore->Notify();
inCAPThread->mWaitSemaphore->Unlock();
#endif
}
inCAPThread->mPThread = 0;
return theAnswer;
}
The signa/Notify l has to be in side the lock/unlock because if you
are waiting for delete and the switch happens right after Unlock
call... you delete the thread object (and also semaphore) before the
notify code can be reached.... during testing this happened after
12 hours....
I will keep you up to date on my progress,
mvo
However, if at some point you run into a case where you have an
attached thread which you know for certain has finished executing and
are finished tracking it, I think the most efficient thing to do to
release the resource at this point is to detach it. There's no reason
you can't detach an attached thread that has finished executing.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden