www.digitalmars.com         C & C++   DMDScript  

D - GC & multiple thread causes program hang

reply dickl <dickl_member pathlink.com> writes:
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;
}
Sep 23 2003
parent reply jhenzie mac.com writes:
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;
}

Sep 23 2003
parent reply "Walter" <walter digitalmars.com> writes:
<jhenzie mac.com> wrote in message news:bkqu8s$24dq$1 digitaldaemon.com...
 It seems that the first call to the garbage collectors causes the

 interesting thing is
 that the Main thread is not deadlocked, amend your example and add the

 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

 alone.

 Walter if you are reading, is there any reason why sychronization

 not present in
 Thread.suspendAll.  I fairly sure you are handling the locking lower down

 would appear
 logica;l to implement the lock on the Thread class.  But again I'm new

 feel free to disabuse
 of that notion.

 More soon.

 Justin

Can you suggest any fixes to thread.d?
Sep 23 2003
parent reply jhenzie mac.com writes:
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

 interesting thing is
 that the Main thread is not deadlocked, amend your example and add the

 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

 alone.

 Walter if you are reading, is there any reason why sychronization

 not present in
 Thread.suspendAll.  I fairly sure you are handling the locking lower down

 would appear
 logica;l to implement the lock on the Thread class.  But again I'm new

 feel free to disabuse
 of that notion.

 More soon.

 Justin

Can you suggest any fixes to thread.d?

Sep 23 2003
parent reply "Walter" <walter digitalmars.com> writes:
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

 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

 operations.  In my
 opinion, a call to pauseAll should leave the calling thread as the only

 thread in the
 process and it should be serial. That is calls to pauseAll should be

 such that if thread1
 calls pauseAll before thread2, thread1 will be the controlling thread when

 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

 with GURU Status,
 after all suspending other threads ignores the possibility that they hold

 on a specific
 resource that the calling thread may soon need.  This is the reason

 resume have been
 deprecated in Java.

 NB:  I realize this may be a somewhat naive view and am willing to be

 <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

 2.  Given the sychronized(object) stnrax ir would seem that every object

 as mutex in D. If
 this is the case perhaps the addition of wait, notify and notifyall, a la

 on object would allow
 for a more flexible and complete approach to multithreading.  Of course

 would require the
 Thread::wait method to be renamed Thread::join <smile/>.  No flames

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

 wanted.

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

 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


 It seems that the first call to the garbage collectors causes the

 interesting thing is
 that the Main thread is not deadlocked, amend your example and add the

 after
 Sleep(10000);

 Thread.resumeAll()

 The application exits as you would expect which tends to point to



 problem. that  of
 threads that are sleeping being ignored as part of a



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



not
 alone.

 Walter if you are reading, is there any reason why sychronization

 not present in
 Thread.suspendAll.  I fairly sure you are handling the locking lower



but it
 would appear
 logica;l to implement the lock on the Thread class.  But again I'm new

 feel free to disabuse
 of that notion.

 More soon.

 Justin

Can you suggest any fixes to thread.d?


Sep 23 2003
next sibling parent reply jhenzie mac.com writes:
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

 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

 operations.  In my
 opinion, a call to pauseAll should leave the calling thread as the only

 thread in the
 process and it should be serial. That is calls to pauseAll should be

 such that if thread1
 calls pauseAll before thread2, thread1 will be the controlling thread when

 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

 with GURU Status,
 after all suspending other threads ignores the possibility that they hold

 on a specific
 resource that the calling thread may soon need.  This is the reason

 resume have been
 deprecated in Java.

 NB:  I realize this may be a somewhat naive view and am willing to be

 <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

 2.  Given the sychronized(object) stnrax ir would seem that every object

 as mutex in D. If
 this is the case perhaps the addition of wait, notify and notifyall, a la

 on object would allow
 for a more flexible and complete approach to multithreading.  Of course

 would require the
 Thread::wait method to be renamed Thread::join <smile/>.  No flames

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

 wanted.

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

 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


 It seems that the first call to the garbage collectors causes the

 interesting thing is
 that the Main thread is not deadlocked, amend your example and add the

 after
 Sleep(10000);

 Thread.resumeAll()

 The application exits as you would expect which tends to point to



 problem. that  of
 threads that are sleeping being ignored as part of a



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



not
 alone.

 Walter if you are reading, is there any reason why sychronization

 not present in
 Thread.suspendAll.  I fairly sure you are handling the locking lower



but it
 would appear
 logica;l to implement the lock on the Thread class.  But again I'm new

 feel free to disabuse
 of that notion.

 More soon.

 Justin

Can you suggest any fixes to thread.d?



Sep 24 2003
parent jhenzie mac.com writes:
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

 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

 operations.  In my
 opinion, a call to pauseAll should leave the calling thread as the only

 thread in the
 process and it should be serial. That is calls to pauseAll should be

 such that if thread1
 calls pauseAll before thread2, thread1 will be the controlling thread when

 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

 with GURU Status,
 after all suspending other threads ignores the possibility that they hold

 on a specific
 resource that the calling thread may soon need.  This is the reason

 resume have been
 deprecated in Java.

 NB:  I realize this may be a somewhat naive view and am willing to be

 <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

 2.  Given the sychronized(object) stnrax ir would seem that every object

 as mutex in D. If
 this is the case perhaps the addition of wait, notify and notifyall, a la

 on object would allow
 for a more flexible and complete approach to multithreading.  Of course

 would require the
 Thread::wait method to be renamed Thread::join <smile/>.  No flames

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

 wanted.

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

 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


 It seems that the first call to the garbage collectors causes the

 interesting thing is
 that the Main thread is not deadlocked, amend your example and add the

 after
 Sleep(10000);

 Thread.resumeAll()

 The application exits as you would expect which tends to point to



 problem. that  of
 threads that are sleeping being ignored as part of a



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



not
 alone.

 Walter if you are reading, is there any reason why sychronization

 not present in
 Thread.suspendAll.  I fairly sure you are handling the locking lower



but it
 would appear
 logica;l to implement the lock on the Thread class.  But again I'm new

 feel free to disabuse
 of that notion.

 More soon.

 Justin

Can you suggest any fixes to thread.d?




Sep 24 2003
prev sibling parent reply dickl <dickl_member pathlink.com> writes:
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

 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

 operations.  In my
 opinion, a call to pauseAll should leave the calling thread as the only

 thread in the
 process and it should be serial. That is calls to pauseAll should be

 such that if thread1
 calls pauseAll before thread2, thread1 will be the controlling thread when

 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

 with GURU Status,
 after all suspending other threads ignores the possibility that they hold

 on a specific
 resource that the calling thread may soon need.  This is the reason

 resume have been
 deprecated in Java.

 NB:  I realize this may be a somewhat naive view and am willing to be

 <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

 2.  Given the sychronized(object) stnrax ir would seem that every object

 as mutex in D. If
 this is the case perhaps the addition of wait, notify and notifyall, a la

 on object would allow
 for a more flexible and complete approach to multithreading.  Of course

 would require the
 Thread::wait method to be renamed Thread::join <smile/>.  No flames

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

 wanted.

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

 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


 It seems that the first call to the garbage collectors causes the

 interesting thing is
 that the Main thread is not deadlocked, amend your example and add the

 after
 Sleep(10000);

 Thread.resumeAll()

 The application exits as you would expect which tends to point to



 problem. that  of
 threads that are sleeping being ignored as part of a



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



not
 alone.

 Walter if you are reading, is there any reason why sychronization

 not present in
 Thread.suspendAll.  I fairly sure you are handling the locking lower



but it
 would appear
 logica;l to implement the lock on the Thread class.  But again I'm new

 feel free to disabuse
 of that notion.

 More soon.

 Justin

Can you suggest any fixes to thread.d?



Sep 24 2003
next sibling parent reply jhenzie mac.com writes:
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

 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

 operations.  In my
 opinion, a call to pauseAll should leave the calling thread as the only

 thread in the
 process and it should be serial. That is calls to pauseAll should be

 such that if thread1
 calls pauseAll before thread2, thread1 will be the controlling thread when

 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

 with GURU Status,
 after all suspending other threads ignores the possibility that they hold

 on a specific
 resource that the calling thread may soon need.  This is the reason

 resume have been
 deprecated in Java.

 NB:  I realize this may be a somewhat naive view and am willing to be

 <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

 2.  Given the sychronized(object) stnrax ir would seem that every object

 as mutex in D. If
 this is the case perhaps the addition of wait, notify and notifyall, a la

 on object would allow
 for a more flexible and complete approach to multithreading.  Of course

 would require the
 Thread::wait method to be renamed Thread::join <smile/>.  No flames

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

 wanted.

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

 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


 It seems that the first call to the garbage collectors causes the

 interesting thing is
 that the Main thread is not deadlocked, amend your example and add the

 after
 Sleep(10000);

 Thread.resumeAll()

 The application exits as you would expect which tends to point to



 problem. that  of
 threads that are sleeping being ignored as part of a



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



not
 alone.

 Walter if you are reading, is there any reason why sychronization

 not present in
 Thread.suspendAll.  I fairly sure you are handling the locking lower



but it
 would appear
 logica;l to implement the lock on the Thread class.  But again I'm new

 feel free to disabuse
 of that notion.

 More soon.

 Justin

Can you suggest any fixes to thread.d?




Sep 24 2003
parent reply dickl <dickl_member pathlink.com> writes:
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

 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

 operations.  In my
 opinion, a call to pauseAll should leave the calling thread as the only

 thread in the
 process and it should be serial. That is calls to pauseAll should be

 such that if thread1
 calls pauseAll before thread2, thread1 will be the controlling thread when

 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

 with GURU Status,
 after all suspending other threads ignores the possibility that they hold

 on a specific
 resource that the calling thread may soon need.  This is the reason

 resume have been
 deprecated in Java.

 NB:  I realize this may be a somewhat naive view and am willing to be

 <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

 2.  Given the sychronized(object) stnrax ir would seem that every object

 as mutex in D. If
 this is the case perhaps the addition of wait, notify and notifyall, a la

 on object would allow
 for a more flexible and complete approach to multithreading.  Of course

 would require the
 Thread::wait method to be renamed Thread::join <smile/>.  No flames

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

 wanted.

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

 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


 It seems that the first call to the garbage collectors causes the

 interesting thing is
 that the Main thread is not deadlocked, amend your example and add the

 after
 Sleep(10000);

 Thread.resumeAll()

 The application exits as you would expect which tends to point to



 problem. that  of
 threads that are sleeping being ignored as part of a



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



not
 alone.

 Walter if you are reading, is there any reason why sychronization

 not present in
 Thread.suspendAll.  I fairly sure you are handling the locking lower



but it
 would appear
 logica;l to implement the lock on the Thread class.  But again I'm new

 feel free to disabuse
 of that notion.

 More soon.

 Justin

Can you suggest any fixes to thread.d?





Sep 24 2003
parent reply jhenzie mac.com writes:
I have written a small C test app on XP and suspending the primary thread has no
effect on the process, execution continues. this makes me think that the primary
is in a critical, and common section when the pause is executed.

My synchronization implementation in thread.d is entirely independent of the gc
synchronization, thread uses threadLock, gc uses gclock, ir seem that the gc,
nenory allocator and thread suspension/resume might need to share a global
lock(s)

I'll let you know how I get on with Linux tonight.

Justin

In article <bkt5ue$25tp$1 digitaldaemon.com>, dickl says...
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

 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

 operations.  In my
 opinion, a call to pauseAll should leave the calling thread as the only

 thread in the
 process and it should be serial. That is calls to pauseAll should be

 such that if thread1
 calls pauseAll before thread2, thread1 will be the controlling thread when

 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

 with GURU Status,
 after all suspending other threads ignores the possibility that they hold

 on a specific
 resource that the calling thread may soon need.  This is the reason

 resume have been
 deprecated in Java.

 NB:  I realize this may be a somewhat naive view and am willing to be

 <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

 2.  Given the sychronized(object) stnrax ir would seem that every object

 as mutex in D. If
 this is the case perhaps the addition of wait, notify and notifyall, a la

 on object would allow
 for a more flexible and complete approach to multithreading.  Of course

 would require the
 Thread::wait method to be renamed Thread::join <smile/>.  No flames

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

 wanted.

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

 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


 It seems that the first call to the garbage collectors causes the

 interesting thing is
 that the Main thread is not deadlocked, amend your example and add the

 after
 Sleep(10000);

 Thread.resumeAll()

 The application exits as you would expect which tends to point to



 problem. that  of
 threads that are sleeping being ignored as part of a



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



not
 alone.

 Walter if you are reading, is there any reason why sychronization

 not present in
 Thread.suspendAll.  I fairly sure you are handling the locking lower



but it
 would appear
 logica;l to implement the lock on the Thread class.  But again I'm new

 feel free to disabuse
 of that notion.

 More soon.

 Justin

Can you suggest any fixes to thread.d?






Sep 24 2003
next sibling parent jhenzie mac.com writes:
Ok so Linux hangs as well but that should not be that much of a suprise since a
process is active in unix and so suspending it means that the process will not
be allocated an cpu time until woken up so it can't schedule threads, of course
this depends on the threading model.  More annoyingly SIGINT is blocked so you
can't ctrl-c tha application, must change that.

I am going to look at the windows code again today because the only reason a
thread would cease to run if its parent thread were paused woul dbe if it were a
fibre.

Let me know if you make any progress.


Justin 





In article <bkt5ue$25tp$1 digitaldaemon.com>, dickl says...
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

 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

 operations.  In my
 opinion, a call to pauseAll should leave the calling thread as the only

 thread in the
 process and it should be serial. That is calls to pauseAll should be

 such that if thread1
 calls pauseAll before thread2, thread1 will be the controlling thread when

 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

 with GURU Status,
 after all suspending other threads ignores the possibility that they hold

 on a specific
 resource that the calling thread may soon need.  This is the reason

 resume have been
 deprecated in Java.

 NB:  I realize this may be a somewhat naive view and am willing to be

 <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

 2.  Given the sychronized(object) stnrax ir would seem that every object

 as mutex in D. If
 this is the case perhaps the addition of wait, notify and notifyall, a la

 on object would allow
 for a more flexible and complete approach to multithreading.  Of course

 would require the
 Thread::wait method to be renamed Thread::join <smile/>.  No flames

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

 wanted.

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

 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


 It seems that the first call to the garbage collectors causes the

 interesting thing is
 that the Main thread is not deadlocked, amend your example and add the

 after
 Sleep(10000);

 Thread.resumeAll()

 The application exits as you would expect which tends to point to



 problem. that  of
 threads that are sleeping being ignored as part of a



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



not
 alone.

 Walter if you are reading, is there any reason why sychronization

 not present in
 Thread.suspendAll.  I fairly sure you are handling the locking lower



but it
 would appear
 logica;l to implement the lock on the Thread class.  But again I'm new

 feel free to disabuse
 of that notion.

 More soon.

 Justin

Can you suggest any fixes to thread.d?







Sep 25 2003
prev sibling parent reply "dickl" <dick221z yahoo.com> writes:
I've looked a the GC code in more detail. It appears anything to do anything
with dynamic memory,  has a call to synchronized() in it. So, it theory, any
thread making a call will wait for any GC in progress. So, I don't see a
need for the calls to thread.pauseAll and thread.resumeAll.

I commented them out in gcx.fullCollect. So far I have not seen any
problems. I've
run my app for a for a few hours with no problems. I also then added another
thread which
calls fullCollect every 1 Sec and have my worker thread calling  fullCollect
every loop (about  every 50mS). Didn't see a problem there either.

For all the tests above, I put that for-loop in pauseAll back the way it
was. I'm not using thread.pauseAll in my app. More checking on the Thread
code is needed to see if pauseAll works ok when used by itself (outside of
the GC code).

The gc code is somewhat disruptive to my worker thread since it is doing
real time signal processing, so I am looking at removing all dynamic memory
stuff from it.


<jhenzie mac.com> wrote in message news:bkt7p3$28e7$1 digitaldaemon.com...
 I have written a small C test app on XP and suspending the primary thread

 effect on the process, execution continues. this makes me think that the

 is in a critical, and common section when the pause is executed.

 My synchronization implementation in thread.d is entirely independent of

 synchronization, thread uses threadLock, gc uses gclock, ir seem that the

 nenory allocator and thread suspension/resume might need to share a global
 lock(s)

 I'll let you know how I get on with Linux tonight.

 Justin

 In article <bkt5ue$25tp$1 digitaldaemon.com>, dickl says...
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


while a child thread is re-arranging memory. Its probably an very


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




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




A better solution would be to put checks in the gc routines so that any




alloc/dealloc waits for collectfull() to finish. There is no reason to




threads which are not alloc/dealloc-ing memory. I don't understand the




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





 Walter

 Let me just say that I am new to D but I can not tell you how much I

 your efforts.  It has
 given me a sense of excitement that I have not felt since






 [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






atomic
 operations.  In my
 opinion, a call to pauseAll should leave the calling thread as the






running
 thread in the
 process and it should be serial. That is calls to pauseAll should be

 such that if thread1
 calls pauseAll before thread2, thread1 will be the controlling






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






people
 with GURU Status,
 after all suspending other threads ignores the possibility that they






a lock
 on a specific
 resource that the calling thread may soon need.  This is the reason

 resume have been
 deprecated in Java.

 NB:  I realize this may be a somewhat naive view and am willing to






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

 2.  Given the sychronized(object) stnrax ir would seem that every






can act
 as mutex in D. If
 this is the case perhaps the addition of wait, notify and notifyall,






java,
 on object would allow
 for a more flexible and complete approach to multithreading.  Of






this
 would require the
 Thread::wait method to be renamed Thread::join <smile/>.  No flames

 I will consider it further and hopefully give as much feedback as I






and is
 wanted.

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






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


 It seems that the first call to the garbage collectors causes the

 interesting thing is
 that the Main thread is not deadlocked, amend your example and








following
 after
 Sleep(10000);

 Thread.resumeAll()

 The application exits as you would expect which tends to point to



 problem. that  of
 threads that are sleeping being ignored as part of a



 I am new to D so it may take me some time to figure this out but








are
not
 alone.

 Walter if you are reading, is there any reason why sychronization

 not present in
 Thread.suspendAll.  I fairly sure you are handling the locking








down
but it
 would appear
 logica;l to implement the lock on the Thread class.  But again








here so
 feel free to disabuse
 of that notion.

 More soon.

 Justin

Can you suggest any fixes to thread.d?







Sep 25 2003
parent reply jhenzie mac.com writes:
Totally agree the synchonized semantics are unnecessary in Thread.

The problem is clearly to do with suspending the primary thread.  On unix one
might expect the app to hang given that what D uses as allThreads[0] is actually
the process, but this does not explain the windows hang since windows processes
are not active.

It is very strange.  

Justin


In article <bkvl68$1s3f$1 digitaldaemon.com>, dickl says...
I've looked a the GC code in more detail. It appears anything to do anything
with dynamic memory,  has a call to synchronized() in it. So, it theory, any
thread making a call will wait for any GC in progress. So, I don't see a
need for the calls to thread.pauseAll and thread.resumeAll.

I commented them out in gcx.fullCollect. So far I have not seen any
problems. I've
run my app for a for a few hours with no problems. I also then added another
thread which
calls fullCollect every 1 Sec and have my worker thread calling  fullCollect
every loop (about  every 50mS). Didn't see a problem there either.

For all the tests above, I put that for-loop in pauseAll back the way it
was. I'm not using thread.pauseAll in my app. More checking on the Thread
code is needed to see if pauseAll works ok when used by itself (outside of
the GC code).

The gc code is somewhat disruptive to my worker thread since it is doing
real time signal processing, so I am looking at removing all dynamic memory
stuff from it.


<jhenzie mac.com> wrote in message news:bkt7p3$28e7$1 digitaldaemon.com...
 I have written a small C test app on XP and suspending the primary thread

 effect on the process, execution continues. this makes me think that the

 is in a critical, and common section when the pause is executed.

 My synchronization implementation in thread.d is entirely independent of

 synchronization, thread uses threadLock, gc uses gclock, ir seem that the

 nenory allocator and thread suspension/resume might need to share a global
 lock(s)

 I'll let you know how I get on with Linux tonight.

 Justin

 In article <bkt5ue$25tp$1 digitaldaemon.com>, dickl says...
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


while a child thread is re-arranging memory. Its probably an very


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




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




A better solution would be to put checks in the gc routines so that any




alloc/dealloc waits for collectfull() to finish. There is no reason to




threads which are not alloc/dealloc-ing memory. I don't understand the




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





 Walter

 Let me just say that I am new to D but I can not tell you how much I

 your efforts.  It has
 given me a sense of excitement that I have not felt since






 [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






atomic
 operations.  In my
 opinion, a call to pauseAll should leave the calling thread as the






running
 thread in the
 process and it should be serial. That is calls to pauseAll should be

 such that if thread1
 calls pauseAll before thread2, thread1 will be the controlling






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






people
 with GURU Status,
 after all suspending other threads ignores the possibility that they






a lock
 on a specific
 resource that the calling thread may soon need.  This is the reason

 resume have been
 deprecated in Java.

 NB:  I realize this may be a somewhat naive view and am willing to






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

 2.  Given the sychronized(object) stnrax ir would seem that every






can act
 as mutex in D. If
 this is the case perhaps the addition of wait, notify and notifyall,






java,
 on object would allow
 for a more flexible and complete approach to multithreading.  Of






this
 would require the
 Thread::wait method to be renamed Thread::join <smile/>.  No flames

 I will consider it further and hopefully give as much feedback as I






and is
 wanted.

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






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


 It seems that the first call to the garbage collectors causes the

 interesting thing is
 that the Main thread is not deadlocked, amend your example and








following
 after
 Sleep(10000);

 Thread.resumeAll()

 The application exits as you would expect which tends to point to



 problem. that  of
 threads that are sleeping being ignored as part of a



 I am new to D so it may take me some time to figure this out but








are
not
 alone.

 Walter if you are reading, is there any reason why sychronization

 not present in
 Thread.suspendAll.  I fairly sure you are handling the locking








down
but it
 would appear
 logica;l to implement the lock on the Thread class.  But again








here so
 feel free to disabuse
 of that notion.

 More soon.

 Justin

Can you suggest any fixes to thread.d?








Sep 25 2003
parent reply "dickl" <dick221z yahoo.com> writes:
The Thread class looks like it needs some work. There isn't a way to kill a
thread and remove if from the list of threads, if the thread completes, you
can't re-start it later on.

Walter, whats the best way to address these issues with the Thread class ?

1) suspending allthread[0] suspends the application in pauseAll()
2) doing a delete on a thread causes problems (no destructor to remove the
thread from the list)
3) letting a thread complete and then restarting it causes problems.(no way
to mark a thread as terminated and allow it  to restarted)
4) the call to pauseAll() and resumeAll() does not seem to be necessary in
gcx.fullcollect()


<jhenzie mac.com> wrote in message news:bkvq9i$2325$1 digitaldaemon.com...
 Totally agree the synchonized semantics are unnecessary in Thread.

 The problem is clearly to do with suspending the primary thread.  On unix

 might expect the app to hang given that what D uses as allThreads[0] is

 the process, but this does not explain the windows hang since windows

 are not active.

 It is very strange.

 Justin


 In article <bkvl68$1s3f$1 digitaldaemon.com>, dickl says...
I've looked a the GC code in more detail. It appears anything to do


with dynamic memory,  has a call to synchronized() in it. So, it theory,


thread making a call will wait for any GC in progress. So, I don't see a
need for the calls to thread.pauseAll and thread.resumeAll.

I commented them out in gcx.fullCollect. So far I have not seen any
problems. I've
run my app for a for a few hours with no problems. I also then added


thread which
calls fullCollect every 1 Sec and have my worker thread calling


every loop (about  every 50mS). Didn't see a problem there either.

For all the tests above, I put that for-loop in pauseAll back the way it
was. I'm not using thread.pauseAll in my app. More checking on the Thread
code is needed to see if pauseAll works ok when used by itself (outside


the GC code).

The gc code is somewhat disruptive to my worker thread since it is doing
real time signal processing, so I am looking at removing all dynamic


stuff from it.


<jhenzie mac.com> wrote in message


 I have written a small C test app on XP and suspending the primary



has no
 effect on the process, execution continues. this makes me think that



primary
 is in a critical, and common section when the pause is executed.

 My synchronization implementation in thread.d is entirely independent



the gc
 synchronization, thread uses threadLock, gc uses gclock, ir seem that



gc,
 nenory allocator and thread suspension/resume might need to share a



 lock(s)

 I'll let you know how I get on with Linux tonight.

 Justin

 In article <bkt5ue$25tp$1 digitaldaemon.com>, dickl says...
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




stuff
while a child thread is re-arranging memory. Its probably an very


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




pause allThreads[0] or the app will freeze. I believe this is






allThreads[0] is the main thread and pausing it will pause all the




A better solution would be to put checks in the gc routines so that






memory
alloc/dealloc waits for collectfull() to finish. There is no reason






pause
threads which are not alloc/dealloc-ing memory. I don't understand






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





 Walter

 Let me just say that I am new to D but I can not tell you how








appeciate
 your efforts.  It has
 given me a sense of excitement that I have not felt since






 [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






atomic
 operations.  In my
 opinion, a call to pauseAll should leave the calling thread as








only
running
 thread in the
 process and it should be serial. That is calls to pauseAll should








serialized
 such that if thread1
 calls pauseAll before thread2, thread1 will be the controlling






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








by
people
 with GURU Status,
 after all suspending other threads ignores the possibility that








hold
a lock
 on a specific
 resource that the calling thread may soon need.  This is the








suspend and
 resume have been
 deprecated in Java.

 NB:  I realize this may be a somewhat naive view and am willing








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

 2.  Given the sychronized(object) stnrax ir would seem that every






can act
 as mutex in D. If
 this is the case perhaps the addition of wait, notify and








a la
java,
 on object would allow
 for a more flexible and complete approach to multithreading.  Of






this
 would require the
 Thread::wait method to be renamed Thread::join <smile/>.  No








please.
 I will consider it further and hopefully give as much feedback as








can
and is
 wanted.

 I will keep looking for the cause of the deadlock and let you








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


 It seems that the first call to the garbage collectors causes










deadlock.  The
 interesting thing is
 that the Main thread is not deadlocked, amend your example and








following
 after
 Sleep(10000);

 Thread.resumeAll()

 The application exits as you would expect which tends to point










another
 problem. that  of
 threads that are sleeping being ignored as part of a



 I am new to D so it may take me some time to figure this out










you
are
not
 alone.

 Walter if you are reading, is there any reason why










semantics are
 not present in
 Thread.suspendAll.  I fairly sure you are handling the locking








down
but it
 would appear
 logica;l to implement the lock on the Thread class.  But again








here so
 feel free to disabuse
 of that notion.

 More soon.

 Justin

Can you suggest any fixes to thread.d?









Sep 26 2003
next sibling parent jhenzie mac.com writes:
At least on windows.  I was so excited by the find that I have not refactored to
make it clean but here is the problem.

On windows GetCurrentThread returns -2  This is a pseudo handle that always
represents the current thread so which ever thread is calling SuspendThread with

allThreads[0].hdl is effectively pausing itself.

The following additions will resolve the problem, walter is there an official
submission form?

***windows.d***

extern (Windows)
{
export BOOL DuplicateHandle (HANDLE sourceProcess, HANDLE sourceThread,
HANDLE targetProcessHandle, HANDLE *targetHandle, DWORD access, 
BOOL inheritHandle, DWORD options);
}

***thread.d***

static this()
{
threadLock = new Object();

Thread t = new Thread();

t.state = TS.RUNNING;
t.id = GetCurrentThreadId();

thread_hdl currentThread = GetCurrentThread();

HANDLE process = (HANDLE)-1;        

DWORD access = (DWORD)0x00000002;

DuplicateHandle(process, currentThread, process, 
&(t.hdl), (DWORD)0, TRUE, access);

t.stackBottom = os_query_stackBottom();
synchronized (threadLock)
{
assert(!allThreads[0]);
allThreads[0] = t;
allThreadsDim = 1;
t.idx = 0;
}
}
Sep 26 2003
prev sibling parent jhenzie mac.com writes:
At least on windows.  I was so excited by the find that I have not refactored to
make it clean but here is the problem.

On windows GetCurrentThread returns -2  This is a pseudo handle that always
represents the current thread so which ever thread is calling SuspendThread with

allThreads[0].hdl is effectively pausing itself.

The following additions will resolve the problem, walter is there an official
submission form?

***windows.d***

extern (Windows)
{
export BOOL DuplicateHandle (HANDLE sourceProcess, HANDLE sourceThread,
HANDLE targetProcessHandle, HANDLE *targetHandle, DWORD access, 
BOOL inheritHandle, DWORD options);
}

***thread.d***

static this()
{
threadLock = new Object();

Thread t = new Thread();

t.state = TS.RUNNING;
t.id = GetCurrentThreadId();

thread_hdl currentThread = GetCurrentThread();

HANDLE process = (HANDLE)-1;        

DWORD access = (DWORD)0x00000002;

DuplicateHandle(process, currentThread, process, 
&(t.hdl), (DWORD)0, TRUE, access);

t.stackBottom = os_query_stackBottom();
synchronized (threadLock)
{
assert(!allThreads[0]);
allThreads[0] = t;
allThreadsDim = 1;
t.idx = 0;
}
}
Sep 26 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"dickl" <dickl_member pathlink.com> wrote in message
news:bkt0sq$1umd$1 digitaldaemon.com...
 There is no reason to pause
 threads which are not alloc/dealloc-ing memory.

Yes, there is, because they may hold (on their stacks) a reference to allocated memory.
Oct 01 2003