View mode: basic / threaded / horizontal-split · Log in · Help
September 23, 2003
GC & multiple thread causes program hang
When an application has multiple threads and if the garbage collection gets
called, the GC pauses all threads. The problem is if the GC was called from
inside a thread that thread is suspended, hanging the application.
If the thread has a long life and is repeatedly allocating/deallocating memory,
GC get called automatically.

--------------------

import thread;
import gc;
import string;

int main(){

Thread foo=new Thread(&testThread,null);
Thread foo1=new Thread(&testThread1,null);
foo.start();
foo1.start();
Sleep(10000);
return 1;
}

int testThread(void *p)
{
while(true)
{
char [] Str;
for(int i=0;i<20;i++)
{
Str="Loop1:"~string.toString(i);
printf("%s\n",cast(char*)Str);
}
fullCollect();
}
return 1;
}

int testThread1(void *p)
{
while(true)
{
char [] Str;
for(int i=0;i<20;i++)
{
Str="Loop2:"~string.toString(i);
printf("%s\n",cast(char*)Str);
}
genCollect();
}
return 1;
}
September 24, 2003
Re: GC & multiple thread causes program hang
That is very interesting my friend.

It seems that the first call to the garbage collectors causes the deadlock.  The
interesting thing is 
that the Main thread is not deadlocked, amend your example and add the following
after 
Sleep(10000);

Thread.resumeAll()

The application exits as you would expect which tends to point to another
problem. that  of 
threads that are sleeping being ignored as part of a Thread.suspendAll()

I am new to D so it may take me some time to figure this out but you are not
alone.

Walter if you are reading, is there any reason why sychronization semantics are
not present in 
Thread.suspendAll.  I fairly sure you are handling the locking lower down but it
would appear 
logica;l to implement the lock on the Thread class.  But again I'm new here so
feel free to disabuse 
of that notion. 

More soon.

Justin





In article <bkpuc1$me5$1@digitaldaemon.com>, dickl says...
>
>When an application has multiple threads and if the garbage collection gets
>called, the GC pauses all threads. The problem is if the GC was called from
>inside a thread that thread is suspended, hanging the application.
>If the thread has a long life and is repeatedly allocating/deallocating memory,
>GC get called automatically.
>
>--------------------
>
>import thread;
>import gc;
>import string;
>
>int main(){
>
>Thread foo=new Thread(&testThread,null);
>Thread foo1=new Thread(&testThread1,null);
>foo.start();
>foo1.start();
>Sleep(10000);
>return 1;
>}
>
>int testThread(void *p)
>{
>while(true)
>{
>char [] Str;
>for(int i=0;i<20;i++)
>{
>Str="Loop1:"~string.toString(i);
>printf("%s\n",cast(char*)Str);
>}
>fullCollect();
>}
>return 1;
>}
>
>int testThread1(void *p)
>{
>while(true)
>{
>char [] Str;
>for(int i=0;i<20;i++)
>{
>Str="Loop2:"~string.toString(i);
>printf("%s\n",cast(char*)Str);
>}
>genCollect();
>}
>return 1;
>}
>
>
>
>
September 24, 2003
Re: GC & multiple thread causes program hang
<jhenzie@mac.com> wrote in message news:bkqu8s$24dq$1@digitaldaemon.com...
> It seems that the first call to the garbage collectors causes the
deadlock.  The
> interesting thing is
> that the Main thread is not deadlocked, amend your example and add the
following
> after
> Sleep(10000);
>
> Thread.resumeAll()
>
> The application exits as you would expect which tends to point to another
> problem. that  of
> threads that are sleeping being ignored as part of a Thread.suspendAll()
>
> I am new to D so it may take me some time to figure this out but you are
not
> alone.
>
> Walter if you are reading, is there any reason why sychronization
semantics are
> not present in
> Thread.suspendAll.  I fairly sure you are handling the locking lower down
but it
> would appear
> logica;l to implement the lock on the Thread class.  But again I'm new
here so
> feel free to disabuse
> of that notion.
>
> More soon.
>
> Justin

Can you suggest any fixes to thread.d?
September 24, 2003
Re: GC & multiple thread causes program hang
Walter

Let me just say that I am new to D but I can not tell you how much I appeciate
your efforts.  It has 
given me a sense of excitement that I have not felt since Objective-C.
[Objective-c retain] by the 
way.

In any case my concerns with the Thread class are as follows.

1.  It seems to me that resumeAll and pauseAll ought to be considered atomic
operations.  In my 
opinion, a call to pauseAll should leave the calling thread as the only running
thread in the 
process and it should be serial. That is calls to pauseAll should be serialized
such that if thread1 
calls pauseAll before thread2, thread1 will be the controlling thread when all
is said and done.  A 
resumeAll will then allow thread2 to take control.  

To my mind this type of call should be extremely rare and only used by people
with GURU Status, 
after all suspending other threads ignores the possibility that they hold a lock
on a specific 
resource that the calling thread may soon need.  This is the reason suspend and
resume have been 
deprecated in Java.

NB:  I realize this may be a somewhat naive view and am willing to be educated.
<smile/>

The most basic approach would be (using resumeAll)

static void resumeAll()
{
if (nthreads > 1)
{
Thread tthis = getThis();

synchronized (threadlock) {
for (int i = 0; i < allThreadsDim; i++)
{   Thread t;

t = allThreads[i];
if (t && t !== tthis && t.state == TS.RUNNING)
t.resume();
}
}
}
}

of course this would require a recursive lock on Thread::resume Thread::pause.

2.  Given the sychronized(object) stnrax ir would seem that every object can act
as mutex in D. If 
this is the case perhaps the addition of wait, notify and notifyall, a la java,
on object would allow 
for a more flexible and complete approach to multithreading.  Of course this
would require the 
Thread::wait method to be renamed Thread::join <smile/>.  No flames please.  

I will consider it further and hopefully give as much feedback as I can and is
wanted.

I will keep looking for the cause of the deadlock and let you know what I find.

What are people using as a D Debugger, is there such a beast?

Justin



In article <bkr2gh$29sc$1@digitaldaemon.com>, Walter says...
>
>
><jhenzie@mac.com> wrote in message news:bkqu8s$24dq$1@digitaldaemon.com...
>> It seems that the first call to the garbage collectors causes the
>deadlock.  The
>> interesting thing is
>> that the Main thread is not deadlocked, amend your example and add the
>following
>> after
>> Sleep(10000);
>>
>> Thread.resumeAll()
>>
>> The application exits as you would expect which tends to point to another
>> problem. that  of
>> threads that are sleeping being ignored as part of a Thread.suspendAll()
>>
>> I am new to D so it may take me some time to figure this out but you are
>not
>> alone.
>>
>> Walter if you are reading, is there any reason why sychronization
>semantics are
>> not present in
>> Thread.suspendAll.  I fairly sure you are handling the locking lower down
>but it
>> would appear
>> logica;l to implement the lock on the Thread class.  But again I'm new
>here so
>> feel free to disabuse
>> of that notion.
>>
>> More soon.
>>
>> Justin
>
>Can you suggest any fixes to thread.d?
>
>
September 24, 2003
Re: GC & multiple thread causes program hang
I think you're on the right track here. If you want to make the
modifications to thread.d, that'd be a great contribution to D!

<jhenzie@mac.com> wrote in message news:bkrbr7$2mhf$1@digitaldaemon.com...
> Walter
>
> Let me just say that I am new to D but I can not tell you how much I
appeciate
> your efforts.  It has
> given me a sense of excitement that I have not felt since Objective-C.
> [Objective-c retain] by the
> way.
>
> In any case my concerns with the Thread class are as follows.
>
> 1.  It seems to me that resumeAll and pauseAll ought to be considered
atomic
> operations.  In my
> opinion, a call to pauseAll should leave the calling thread as the only
running
> thread in the
> process and it should be serial. That is calls to pauseAll should be
serialized
> such that if thread1
> calls pauseAll before thread2, thread1 will be the controlling thread when
all
> is said and done.  A
> resumeAll will then allow thread2 to take control.
>
> To my mind this type of call should be extremely rare and only used by
people
> with GURU Status,
> after all suspending other threads ignores the possibility that they hold
a lock
> on a specific
> resource that the calling thread may soon need.  This is the reason
suspend and
> resume have been
> deprecated in Java.
>
> NB:  I realize this may be a somewhat naive view and am willing to be
educated.
> <smile/>
>
> The most basic approach would be (using resumeAll)
>
> static void resumeAll()
> {
> if (nthreads > 1)
> {
> Thread tthis = getThis();
>
> synchronized (threadlock) {
> for (int i = 0; i < allThreadsDim; i++)
> {   Thread t;
>
> t = allThreads[i];
> if (t && t !== tthis && t.state == TS.RUNNING)
> t.resume();
> }
> }
> }
> }
>
> of course this would require a recursive lock on Thread::resume
Thread::pause.
>
> 2.  Given the sychronized(object) stnrax ir would seem that every object
can act
> as mutex in D. If
> this is the case perhaps the addition of wait, notify and notifyall, a la
java,
> on object would allow
> for a more flexible and complete approach to multithreading.  Of course
this
> would require the
> Thread::wait method to be renamed Thread::join <smile/>.  No flames
please.
>
> I will consider it further and hopefully give as much feedback as I can
and is
> wanted.
>
> I will keep looking for the cause of the deadlock and let you know what I
find.
>
> What are people using as a D Debugger, is there such a beast?
>
> Justin
>
>
>
> In article <bkr2gh$29sc$1@digitaldaemon.com>, Walter says...
> >
> >
> ><jhenzie@mac.com> wrote in message
news:bkqu8s$24dq$1@digitaldaemon.com...
> >> It seems that the first call to the garbage collectors causes the
> >deadlock.  The
> >> interesting thing is
> >> that the Main thread is not deadlocked, amend your example and add the
> >following
> >> after
> >> Sleep(10000);
> >>
> >> Thread.resumeAll()
> >>
> >> The application exits as you would expect which tends to point to
another
> >> problem. that  of
> >> threads that are sleeping being ignored as part of a
Thread.suspendAll()
> >>
> >> I am new to D so it may take me some time to figure this out but you
are
> >not
> >> alone.
> >>
> >> Walter if you are reading, is there any reason why sychronization
> >semantics are
> >> not present in
> >> Thread.suspendAll.  I fairly sure you are handling the locking lower
down
> >but it
> >> would appear
> >> logica;l to implement the lock on the Thread class.  But again I'm new
> >here so
> >> feel free to disabuse
> >> of that notion.
> >>
> >> More soon.
> >>
> >> Justin
> >
> >Can you suggest any fixes to thread.d?
> >
> >
>
>
September 24, 2003
Re: GC & multiple thread causes program hang
with pleasure.

n article <bkrhoh$2vhg$1@digitaldaemon.com>, Walter says...
>
>I think you're on the right track here. If you want to make the
>modifications to thread.d, that'd be a great contribution to D!
>
><jhenzie@mac.com> wrote in message news:bkrbr7$2mhf$1@digitaldaemon.com...
>> Walter
>>
>> Let me just say that I am new to D but I can not tell you how much I
>appeciate
>> your efforts.  It has
>> given me a sense of excitement that I have not felt since Objective-C.
>> [Objective-c retain] by the
>> way.
>>
>> In any case my concerns with the Thread class are as follows.
>>
>> 1.  It seems to me that resumeAll and pauseAll ought to be considered
>atomic
>> operations.  In my
>> opinion, a call to pauseAll should leave the calling thread as the only
>running
>> thread in the
>> process and it should be serial. That is calls to pauseAll should be
>serialized
>> such that if thread1
>> calls pauseAll before thread2, thread1 will be the controlling thread when
>all
>> is said and done.  A
>> resumeAll will then allow thread2 to take control.
>>
>> To my mind this type of call should be extremely rare and only used by
>people
>> with GURU Status,
>> after all suspending other threads ignores the possibility that they hold
>a lock
>> on a specific
>> resource that the calling thread may soon need.  This is the reason
>suspend and
>> resume have been
>> deprecated in Java.
>>
>> NB:  I realize this may be a somewhat naive view and am willing to be
>educated.
>> <smile/>
>>
>> The most basic approach would be (using resumeAll)
>>
>> static void resumeAll()
>> {
>> if (nthreads > 1)
>> {
>> Thread tthis = getThis();
>>
>> synchronized (threadlock) {
>> for (int i = 0; i < allThreadsDim; i++)
>> {   Thread t;
>>
>> t = allThreads[i];
>> if (t && t !== tthis && t.state == TS.RUNNING)
>> t.resume();
>> }
>> }
>> }
>> }
>>
>> of course this would require a recursive lock on Thread::resume
>Thread::pause.
>>
>> 2.  Given the sychronized(object) stnrax ir would seem that every object
>can act
>> as mutex in D. If
>> this is the case perhaps the addition of wait, notify and notifyall, a la
>java,
>> on object would allow
>> for a more flexible and complete approach to multithreading.  Of course
>this
>> would require the
>> Thread::wait method to be renamed Thread::join <smile/>.  No flames
>please.
>>
>> I will consider it further and hopefully give as much feedback as I can
>and is
>> wanted.
>>
>> I will keep looking for the cause of the deadlock and let you know what I
>find.
>>
>> What are people using as a D Debugger, is there such a beast?
>>
>> Justin
>>
>>
>>
>> In article <bkr2gh$29sc$1@digitaldaemon.com>, Walter says...
>> >
>> >
>> ><jhenzie@mac.com> wrote in message
>news:bkqu8s$24dq$1@digitaldaemon.com...
>> >> It seems that the first call to the garbage collectors causes the
>> >deadlock.  The
>> >> interesting thing is
>> >> that the Main thread is not deadlocked, amend your example and add the
>> >following
>> >> after
>> >> Sleep(10000);
>> >>
>> >> Thread.resumeAll()
>> >>
>> >> The application exits as you would expect which tends to point to
>another
>> >> problem. that  of
>> >> threads that are sleeping being ignored as part of a
>Thread.suspendAll()
>> >>
>> >> I am new to D so it may take me some time to figure this out but you
>are
>> >not
>> >> alone.
>> >>
>> >> Walter if you are reading, is there any reason why sychronization
>> >semantics are
>> >> not present in
>> >> Thread.suspendAll.  I fairly sure you are handling the locking lower
>down
>> >but it
>> >> would appear
>> >> logica;l to implement the lock on the Thread class.  But again I'm new
>> >here so
>> >> feel free to disabuse
>> >> of that notion.
>> >>
>> >> More soon.
>> >>
>> >> Justin
>> >
>> >Can you suggest any fixes to thread.d?
>> >
>> >
>>
>>
>
>
September 24, 2003
Re: GC & multiple thread causes program hang
I've added synchronized() to Thread.pauseAll. I have also found that you can not
pause allThreads[0] or the app will freeze. I believe this is because
allThreads[0] is the main thread and pausing it will pause all the children.

A better solution would be to put checks in the gc routines so that any memory
alloc/dealloc waits for collectfull() to finish. There is no reason to pause
threads which are not alloc/dealloc-ing memory. I don't understand the gc enough
yet to suggest a change.



static void pauseAll()
{
if (nthreads > 1)
{
synchronized (threadLock)
{
Thread tthis = getThis();
for (int i = 1; i < allThreadsDim; i++)
{   
Thread t;
t = allThreads[i];
if (t && t !== tthis && t.state == TS.RUNNING)
t.pause();
}
}
}
}
=============================
In article <bkrhoh$2vhg$1@digitaldaemon.com>, Walter says...
>
>I think you're on the right track here. If you want to make the
>modifications to thread.d, that'd be a great contribution to D!
>
><jhenzie@mac.com> wrote in message news:bkrbr7$2mhf$1@digitaldaemon.com...
>> Walter
>>
>> Let me just say that I am new to D but I can not tell you how much I
>appeciate
>> your efforts.  It has
>> given me a sense of excitement that I have not felt since Objective-C.
>> [Objective-c retain] by the
>> way.
>>
>> In any case my concerns with the Thread class are as follows.
>>
>> 1.  It seems to me that resumeAll and pauseAll ought to be considered
>atomic
>> operations.  In my
>> opinion, a call to pauseAll should leave the calling thread as the only
>running
>> thread in the
>> process and it should be serial. That is calls to pauseAll should be
>serialized
>> such that if thread1
>> calls pauseAll before thread2, thread1 will be the controlling thread when
>all
>> is said and done.  A
>> resumeAll will then allow thread2 to take control.
>>
>> To my mind this type of call should be extremely rare and only used by
>people
>> with GURU Status,
>> after all suspending other threads ignores the possibility that they hold
>a lock
>> on a specific
>> resource that the calling thread may soon need.  This is the reason
>suspend and
>> resume have been
>> deprecated in Java.
>>
>> NB:  I realize this may be a somewhat naive view and am willing to be
>educated.
>> <smile/>
>>
>> The most basic approach would be (using resumeAll)
>>
>> static void resumeAll()
>> {
>> if (nthreads > 1)
>> {
>> Thread tthis = getThis();
>>
>> synchronized (threadlock) {
>> for (int i = 0; i < allThreadsDim; i++)
>> {   Thread t;
>>
>> t = allThreads[i];
>> if (t && t !== tthis && t.state == TS.RUNNING)
>> t.resume();
>> }
>> }
>> }
>> }
>>
>> of course this would require a recursive lock on Thread::resume
>Thread::pause.
>>
>> 2.  Given the sychronized(object) stnrax ir would seem that every object
>can act
>> as mutex in D. If
>> this is the case perhaps the addition of wait, notify and notifyall, a la
>java,
>> on object would allow
>> for a more flexible and complete approach to multithreading.  Of course
>this
>> would require the
>> Thread::wait method to be renamed Thread::join <smile/>.  No flames
>please.
>>
>> I will consider it further and hopefully give as much feedback as I can
>and is
>> wanted.
>>
>> I will keep looking for the cause of the deadlock and let you know what I
>find.
>>
>> What are people using as a D Debugger, is there such a beast?
>>
>> Justin
>>
>>
>>
>> In article <bkr2gh$29sc$1@digitaldaemon.com>, Walter says...
>> >
>> >
>> ><jhenzie@mac.com> wrote in message
>news:bkqu8s$24dq$1@digitaldaemon.com...
>> >> It seems that the first call to the garbage collectors causes the
>> >deadlock.  The
>> >> interesting thing is
>> >> that the Main thread is not deadlocked, amend your example and add the
>> >following
>> >> after
>> >> Sleep(10000);
>> >>
>> >> Thread.resumeAll()
>> >>
>> >> The application exits as you would expect which tends to point to
>another
>> >> problem. that  of
>> >> threads that are sleeping being ignored as part of a
>Thread.suspendAll()
>> >>
>> >> I am new to D so it may take me some time to figure this out but you
>are
>> >not
>> >> alone.
>> >>
>> >> Walter if you are reading, is there any reason why sychronization
>> >semantics are
>> >> not present in
>> >> Thread.suspendAll.  I fairly sure you are handling the locking lower
>down
>> >but it
>> >> would appear
>> >> logica;l to implement the lock on the Thread class.  But again I'm new
>> >here so
>> >> feel free to disabuse
>> >> of that notion.
>> >>
>> >> More soon.
>> >>
>> >> Justin
>> >
>> >Can you suggest any fixes to thread.d?
>> >
>> >
>>
>>
>
>
September 24, 2003
Re: GC & multiple thread causes program hang
Has anyone run the test code on Linux?

Ok  I have added synchronization to pause(All), resume(All) so we have atomicity
here.  I think this is a good thing but it is not the problem.

In fact the problem is not even in the Garbage collection code. no sir.

pausing and resuming threads in fact works like a champ, so much so that I think
it might be worth removing the synchronization or at least offering an
alternative strategy.  But that's for the future.

The problem is that calling SuspendThread on allThreads[0], the primary thread,
halts the application in its tracks.  The call to SuspendThread never returns.
Removing all synchronization results in the same, the SuspendThread method must
have its own syunchronization semantics whereas the ones I have implemented are
more relevant to expected behavior.

Any win32 Gurus who want to interject, please do, it was myunderstanding that
the primary thread of an application could be suspended, although one always
runs the risk of suspending the thread in a critical section, say memory
allocation, bringing the app to its knees.

I'll keep looking but any ideas would be welcome, I'll try linux tonight.

Justin 


Walter is there anything significant about the 

In article <bks4on$mq2$1@digitaldaemon.com>, jhenzie@mac.com says...
>
>with pleasure.
>
>n article <bkrhoh$2vhg$1@digitaldaemon.com>, Walter says...
>>
>>I think you're on the right track here. If you want to make the
>>modifications to thread.d, that'd be a great contribution to D!
>>
>><jhenzie@mac.com> wrote in message news:bkrbr7$2mhf$1@digitaldaemon.com...
>>> Walter
>>>
>>> Let me just say that I am new to D but I can not tell you how much I
>>appeciate
>>> your efforts.  It has
>>> given me a sense of excitement that I have not felt since Objective-C.
>>> [Objective-c retain] by the
>>> way.
>>>
>>> In any case my concerns with the Thread class are as follows.
>>>
>>> 1.  It seems to me that resumeAll and pauseAll ought to be considered
>>atomic
>>> operations.  In my
>>> opinion, a call to pauseAll should leave the calling thread as the only
>>running
>>> thread in the
>>> process and it should be serial. That is calls to pauseAll should be
>>serialized
>>> such that if thread1
>>> calls pauseAll before thread2, thread1 will be the controlling thread when
>>all
>>> is said and done.  A
>>> resumeAll will then allow thread2 to take control.
>>>
>>> To my mind this type of call should be extremely rare and only used by
>>people
>>> with GURU Status,
>>> after all suspending other threads ignores the possibility that they hold
>>a lock
>>> on a specific
>>> resource that the calling thread may soon need.  This is the reason
>>suspend and
>>> resume have been
>>> deprecated in Java.
>>>
>>> NB:  I realize this may be a somewhat naive view and am willing to be
>>educated.
>>> <smile/>
>>>
>>> The most basic approach would be (using resumeAll)
>>>
>>> static void resumeAll()
>>> {
>>> if (nthreads > 1)
>>> {
>>> Thread tthis = getThis();
>>>
>>> synchronized (threadlock) {
>>> for (int i = 0; i < allThreadsDim; i++)
>>> {   Thread t;
>>>
>>> t = allThreads[i];
>>> if (t && t !== tthis && t.state == TS.RUNNING)
>>> t.resume();
>>> }
>>> }
>>> }
>>> }
>>>
>>> of course this would require a recursive lock on Thread::resume
>>Thread::pause.
>>>
>>> 2.  Given the sychronized(object) stnrax ir would seem that every object
>>can act
>>> as mutex in D. If
>>> this is the case perhaps the addition of wait, notify and notifyall, a la
>>java,
>>> on object would allow
>>> for a more flexible and complete approach to multithreading.  Of course
>>this
>>> would require the
>>> Thread::wait method to be renamed Thread::join <smile/>.  No flames
>>please.
>>>
>>> I will consider it further and hopefully give as much feedback as I can
>>and is
>>> wanted.
>>>
>>> I will keep looking for the cause of the deadlock and let you know what I
>>find.
>>>
>>> What are people using as a D Debugger, is there such a beast?
>>>
>>> Justin
>>>
>>>
>>>
>>> In article <bkr2gh$29sc$1@digitaldaemon.com>, Walter says...
>>> >
>>> >
>>> ><jhenzie@mac.com> wrote in message
>>news:bkqu8s$24dq$1@digitaldaemon.com...
>>> >> It seems that the first call to the garbage collectors causes the
>>> >deadlock.  The
>>> >> interesting thing is
>>> >> that the Main thread is not deadlocked, amend your example and add the
>>> >following
>>> >> after
>>> >> Sleep(10000);
>>> >>
>>> >> Thread.resumeAll()
>>> >>
>>> >> The application exits as you would expect which tends to point to
>>another
>>> >> problem. that  of
>>> >> threads that are sleeping being ignored as part of a
>>Thread.suspendAll()
>>> >>
>>> >> I am new to D so it may take me some time to figure this out but you
>>are
>>> >not
>>> >> alone.
>>> >>
>>> >> Walter if you are reading, is there any reason why sychronization
>>> >semantics are
>>> >> not present in
>>> >> Thread.suspendAll.  I fairly sure you are handling the locking lower
>>down
>>> >but it
>>> >> would appear
>>> >> logica;l to implement the lock on the Thread class.  But again I'm new
>>> >here so
>>> >> feel free to disabuse
>>> >> of that notion.
>>> >>
>>> >> More soon.
>>> >>
>>> >> Justin
>>> >
>>> >Can you suggest any fixes to thread.d?
>>> >
>>> >
>>>
>>>
>>
>>
>
>
September 24, 2003
Re: GC & multiple thread causes program hang
I have found the same results, see previous.

Are you running on Win or Lin?




In article <bkt0sq$1umd$1@digitaldaemon.com>, dickl says...
>
>I've added synchronized() to Thread.pauseAll. I have also found that you can not
>pause allThreads[0] or the app will freeze. I believe this is because
>allThreads[0] is the main thread and pausing it will pause all the children.
>
>A better solution would be to put checks in the gc routines so that any memory
>alloc/dealloc waits for collectfull() to finish. There is no reason to pause
>threads which are not alloc/dealloc-ing memory. I don't understand the gc enough
>yet to suggest a change.
>
>
>
>static void pauseAll()
>{
>if (nthreads > 1)
>{
>synchronized (threadLock)
>{
>Thread tthis = getThis();
>for (int i = 1; i < allThreadsDim; i++)
>{   
>Thread t;
>t = allThreads[i];
>if (t && t !== tthis && t.state == TS.RUNNING)
>t.pause();
>}
>}
>}
>}
>=============================
>In article <bkrhoh$2vhg$1@digitaldaemon.com>, Walter says...
>>
>>I think you're on the right track here. If you want to make the
>>modifications to thread.d, that'd be a great contribution to D!
>>
>><jhenzie@mac.com> wrote in message news:bkrbr7$2mhf$1@digitaldaemon.com...
>>> Walter
>>>
>>> Let me just say that I am new to D but I can not tell you how much I
>>appeciate
>>> your efforts.  It has
>>> given me a sense of excitement that I have not felt since Objective-C.
>>> [Objective-c retain] by the
>>> way.
>>>
>>> In any case my concerns with the Thread class are as follows.
>>>
>>> 1.  It seems to me that resumeAll and pauseAll ought to be considered
>>atomic
>>> operations.  In my
>>> opinion, a call to pauseAll should leave the calling thread as the only
>>running
>>> thread in the
>>> process and it should be serial. That is calls to pauseAll should be
>>serialized
>>> such that if thread1
>>> calls pauseAll before thread2, thread1 will be the controlling thread when
>>all
>>> is said and done.  A
>>> resumeAll will then allow thread2 to take control.
>>>
>>> To my mind this type of call should be extremely rare and only used by
>>people
>>> with GURU Status,
>>> after all suspending other threads ignores the possibility that they hold
>>a lock
>>> on a specific
>>> resource that the calling thread may soon need.  This is the reason
>>suspend and
>>> resume have been
>>> deprecated in Java.
>>>
>>> NB:  I realize this may be a somewhat naive view and am willing to be
>>educated.
>>> <smile/>
>>>
>>> The most basic approach would be (using resumeAll)
>>>
>>> static void resumeAll()
>>> {
>>> if (nthreads > 1)
>>> {
>>> Thread tthis = getThis();
>>>
>>> synchronized (threadlock) {
>>> for (int i = 0; i < allThreadsDim; i++)
>>> {   Thread t;
>>>
>>> t = allThreads[i];
>>> if (t && t !== tthis && t.state == TS.RUNNING)
>>> t.resume();
>>> }
>>> }
>>> }
>>> }
>>>
>>> of course this would require a recursive lock on Thread::resume
>>Thread::pause.
>>>
>>> 2.  Given the sychronized(object) stnrax ir would seem that every object
>>can act
>>> as mutex in D. If
>>> this is the case perhaps the addition of wait, notify and notifyall, a la
>>java,
>>> on object would allow
>>> for a more flexible and complete approach to multithreading.  Of course
>>this
>>> would require the
>>> Thread::wait method to be renamed Thread::join <smile/>.  No flames
>>please.
>>>
>>> I will consider it further and hopefully give as much feedback as I can
>>and is
>>> wanted.
>>>
>>> I will keep looking for the cause of the deadlock and let you know what I
>>find.
>>>
>>> What are people using as a D Debugger, is there such a beast?
>>>
>>> Justin
>>>
>>>
>>>
>>> In article <bkr2gh$29sc$1@digitaldaemon.com>, Walter says...
>>> >
>>> >
>>> ><jhenzie@mac.com> wrote in message
>>news:bkqu8s$24dq$1@digitaldaemon.com...
>>> >> It seems that the first call to the garbage collectors causes the
>>> >deadlock.  The
>>> >> interesting thing is
>>> >> that the Main thread is not deadlocked, amend your example and add the
>>> >following
>>> >> after
>>> >> Sleep(10000);
>>> >>
>>> >> Thread.resumeAll()
>>> >>
>>> >> The application exits as you would expect which tends to point to
>>another
>>> >> problem. that  of
>>> >> threads that are sleeping being ignored as part of a
>>Thread.suspendAll()
>>> >>
>>> >> I am new to D so it may take me some time to figure this out but you
>>are
>>> >not
>>> >> alone.
>>> >>
>>> >> Walter if you are reading, is there any reason why sychronization
>>> >semantics are
>>> >> not present in
>>> >> Thread.suspendAll.  I fairly sure you are handling the locking lower
>>down
>>> >but it
>>> >> would appear
>>> >> logica;l to implement the lock on the Thread class.  But again I'm new
>>> >here so
>>> >> feel free to disabuse
>>> >> of that notion.
>>> >>
>>> >> More soon.
>>> >>
>>> >> Justin
>>> >
>>> >Can you suggest any fixes to thread.d?
>>> >
>>> >
>>>
>>>
>>
>>
>
>
September 24, 2003
Re: GC & multiple thread causes program hang
I'm running XP.

I don't think the synchronized() call is needed in resumeAll..
The synchronized call in pauseAll should keep the main thread from doing stuff
while a child thread is re-arranging memory. Its probably an very uncommon for
this to happen.

I plan on taking a more serious look at the gc tomorrow..
--------------
In article <bkt1ne$1vvi$1@digitaldaemon.com>, jhenzie@mac.com says...
>
>I have found the same results, see previous.
>
>Are you running on Win or Lin?
>
>
>
>
>In article <bkt0sq$1umd$1@digitaldaemon.com>, dickl says...
>>
>>I've added synchronized() to Thread.pauseAll. I have also found that you can not
>>pause allThreads[0] or the app will freeze. I believe this is because
>>allThreads[0] is the main thread and pausing it will pause all the children.
>>
>>A better solution would be to put checks in the gc routines so that any memory
>>alloc/dealloc waits for collectfull() to finish. There is no reason to pause
>>threads which are not alloc/dealloc-ing memory. I don't understand the gc enough
>>yet to suggest a change.
>>
>>
>>
>>static void pauseAll()
>>{
>>if (nthreads > 1)
>>{
>>synchronized (threadLock)
>>{
>>Thread tthis = getThis();
>>for (int i = 1; i < allThreadsDim; i++)
>>{   
>>Thread t;
>>t = allThreads[i];
>>if (t && t !== tthis && t.state == TS.RUNNING)
>>t.pause();
>>}
>>}
>>}
>>}
>>=============================
>>In article <bkrhoh$2vhg$1@digitaldaemon.com>, Walter says...
>>>
>>>I think you're on the right track here. If you want to make the
>>>modifications to thread.d, that'd be a great contribution to D!
>>>
>>><jhenzie@mac.com> wrote in message news:bkrbr7$2mhf$1@digitaldaemon.com...
>>>> Walter
>>>>
>>>> Let me just say that I am new to D but I can not tell you how much I
>>>appeciate
>>>> your efforts.  It has
>>>> given me a sense of excitement that I have not felt since Objective-C.
>>>> [Objective-c retain] by the
>>>> way.
>>>>
>>>> In any case my concerns with the Thread class are as follows.
>>>>
>>>> 1.  It seems to me that resumeAll and pauseAll ought to be considered
>>>atomic
>>>> operations.  In my
>>>> opinion, a call to pauseAll should leave the calling thread as the only
>>>running
>>>> thread in the
>>>> process and it should be serial. That is calls to pauseAll should be
>>>serialized
>>>> such that if thread1
>>>> calls pauseAll before thread2, thread1 will be the controlling thread when
>>>all
>>>> is said and done.  A
>>>> resumeAll will then allow thread2 to take control.
>>>>
>>>> To my mind this type of call should be extremely rare and only used by
>>>people
>>>> with GURU Status,
>>>> after all suspending other threads ignores the possibility that they hold
>>>a lock
>>>> on a specific
>>>> resource that the calling thread may soon need.  This is the reason
>>>suspend and
>>>> resume have been
>>>> deprecated in Java.
>>>>
>>>> NB:  I realize this may be a somewhat naive view and am willing to be
>>>educated.
>>>> <smile/>
>>>>
>>>> The most basic approach would be (using resumeAll)
>>>>
>>>> static void resumeAll()
>>>> {
>>>> if (nthreads > 1)
>>>> {
>>>> Thread tthis = getThis();
>>>>
>>>> synchronized (threadlock) {
>>>> for (int i = 0; i < allThreadsDim; i++)
>>>> {   Thread t;
>>>>
>>>> t = allThreads[i];
>>>> if (t && t !== tthis && t.state == TS.RUNNING)
>>>> t.resume();
>>>> }
>>>> }
>>>> }
>>>> }
>>>>
>>>> of course this would require a recursive lock on Thread::resume
>>>Thread::pause.
>>>>
>>>> 2.  Given the sychronized(object) stnrax ir would seem that every object
>>>can act
>>>> as mutex in D. If
>>>> this is the case perhaps the addition of wait, notify and notifyall, a la
>>>java,
>>>> on object would allow
>>>> for a more flexible and complete approach to multithreading.  Of course
>>>this
>>>> would require the
>>>> Thread::wait method to be renamed Thread::join <smile/>.  No flames
>>>please.
>>>>
>>>> I will consider it further and hopefully give as much feedback as I can
>>>and is
>>>> wanted.
>>>>
>>>> I will keep looking for the cause of the deadlock and let you know what I
>>>find.
>>>>
>>>> What are people using as a D Debugger, is there such a beast?
>>>>
>>>> Justin
>>>>
>>>>
>>>>
>>>> In article <bkr2gh$29sc$1@digitaldaemon.com>, Walter says...
>>>> >
>>>> >
>>>> ><jhenzie@mac.com> wrote in message
>>>news:bkqu8s$24dq$1@digitaldaemon.com...
>>>> >> It seems that the first call to the garbage collectors causes the
>>>> >deadlock.  The
>>>> >> interesting thing is
>>>> >> that the Main thread is not deadlocked, amend your example and add the
>>>> >following
>>>> >> after
>>>> >> Sleep(10000);
>>>> >>
>>>> >> Thread.resumeAll()
>>>> >>
>>>> >> The application exits as you would expect which tends to point to
>>>another
>>>> >> problem. that  of
>>>> >> threads that are sleeping being ignored as part of a
>>>Thread.suspendAll()
>>>> >>
>>>> >> I am new to D so it may take me some time to figure this out but you
>>>are
>>>> >not
>>>> >> alone.
>>>> >>
>>>> >> Walter if you are reading, is there any reason why sychronization
>>>> >semantics are
>>>> >> not present in
>>>> >> Thread.suspendAll.  I fairly sure you are handling the locking lower
>>>down
>>>> >but it
>>>> >> would appear
>>>> >> logica;l to implement the lock on the Thread class.  But again I'm new
>>>> >here so
>>>> >> feel free to disabuse
>>>> >> of that notion.
>>>> >>
>>>> >> More soon.
>>>> >>
>>>> >> Justin
>>>> >
>>>> >Can you suggest any fixes to thread.d?
>>>> >
>>>> >
>>>>
>>>>
>>>
>>>
>>
>>
>
>
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home