Romano Paolo Tenca | 1 Jun 17:55 2006
Picon

Re: mingw + pthreads-w32

Romano Paolo Tenca wrote:
> Thread library Pthreads-w32 (http://sourceware.org/pthreads-win32) can 
> be used with mingw32 and GC or GC supports only Cygwin pthreads  under 
> Windows?
>
If someone is interested: was not hard to use GC Cygwin pthread code 
(with small changes) to support Pthreads-w32under Mingw32  and,  from 
first tests, it seems to work well (and seems also fast).

--

-- 
Romano Paolo Tenca
Hans Boehm | 4 Jun 06:48 2006
Picon

Re: External thread suspension (again)

Sorry about the slow resposne.

In general, this also looks like a better approach to me.  Thanks.

Some comments/questions:

1) I don't see where the SUSPENDED flag gets set in response to
GC_suspend_thread.  It gets set in GC_suspend_self(), but I don't
think you get there unless it has already been set?

2) You should probably call GC_brief_async_signal_safe_sleep().
Last time I looked nanosleep wasn't technically async-signal-safe,
but I think select() always has been.

3) Have you thought about the various possible signal races, and which
signals are masked at what point?  I haven't yet had a chance to.  It
may be fine, but if there's an obvious argument that it is, a
comment would be great.

4) IIRC, GC_start_blocking() has a fundamental issue in that there isn't
really a good way to guarantee that all callee-saves registers are visible
onthe stack at the right point.  The result might be very occasional
failures.  So long as this is used only for debugging, and since this
is fixed with an interface change in 7.0, which can be easily accomodated
by your patch, I'd lean towards ignoring this for now.  The more
ambitious, and more correct, solution would be to backport the gc7
do_blocking() code.

Hans

(Continue reading)

Keith Seitz | 5 Jun 22:43 2006
Picon

Re: External thread suspension (again)

Hans Boehm wrote:

> Some comments/questions:
> 
> 1) I don't see where the SUSPENDED flag gets set in response to
> GC_suspend_thread.  It gets set in GC_suspend_self(), but I don't
> think you get there unless it has already been set?

That gets set in GC_suspend_self. When GC_stop_world is called, 
GC_suspend_all will not signal the externally suspended thread (because 
GC_start_blocking will set thread_blocked).

> 2) You should probably call GC_brief_async_signal_safe_sleep().
> Last time I looked nanosleep wasn't technically async-signal-safe,
> but I think select() always has been.

I've changed that. Thanks.

> 3) Have you thought about the various possible signal races, and which
> signals are masked at what point?  I haven't yet had a chance to.  It
> may be fine, but if there's an obvious argument that it is, a
> comment would be great.

I've thought about it a bit, and the only problem that I see is in the 
signal handler code. *If* a non-blocked signal were to make it to an 
externally suspended thread (and we ended up in our signal handler), it 
would GC_suspend_self itself again. In which case, we would need to 
differentiate between a thread that is supposed to suspend itself and a 
thread which is already suspended.

(Continue reading)

Boehm, Hans | 6 Jun 00:53 2006
Picon

RE: GC_thread_exit_proc error on win32_threads.c

Can you track this down to a particular instruction that generates the segmentation fault?  This sounds like a possible race in the pthread_cleanup implementation.  Do you use thread cancellation?
 
Hans

From: gc-bounces-o/PNRNCSakrWxDs0y9d3MAC/G2K4zDHf@public.gmane.org [mailto:gc-bounces-o/PNRNCSakrWxDs0y9d3MAC/G2K4zDHf@public.gmane.org] On Behalf Of Tommaso Tagliapietra (EXT VE SYS)
Sent: Monday, May 29, 2006 2:24 AM
To: gc-o/PNRNCSakrWxDs0y9d3MAC/G2K4zDHf@public.gmane.org
Subject: [Gc] GC_thread_exit_proc error on win32_threads.c

In a Pentium4 2.6Ghz with WindowsXP Professional SP2, I have a problem with the release 6.4 of the garbage collector under Cygwin, and probably with other releases of the collector.  It seems that at the end of GC_thread_exit_proc (win32_threads.c module), sometimes my program exit with a Segmentation Fault. I'm sure that there is not my code the problem and probably not the Garbage Collector too. However I've resolved the problem adding a "Sleep(10);" at the end of the function:
 
 
void GC_thread_exit_proc(void *arg)
{
    GC_thread me = (GC_thread)arg;
#   if DEBUG_CYGWIN_THREADS
      GC_printf2("thread 0x%x(0x%x) called pthread_exit().\n",
                 (int)pthread_self(), GetCurrentThreadId());
#   endif
 
    LOCK();
    if (me -> flags & DETACHED) {
      GC_delete_thread(GetCurrentThreadId());
    } else {
      /* deallocate it as part of join */
      me -> flags |= FINISHED;
    }
    UNLOCK();
    Sleep(10);
}
 
 
The same problem doesn't not happen into a P4 2Ghz WindowsXP Professional SP2. Same compiler. Why this stupid change works without segmentation fault? Can be some race conditions the reason?
 
_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Picon

Re: GC_thread_exit_proc error on win32_threads.c

All threads are created with PTHREAD_CREATE_JOINABLE | PTHREAD_CREATE_DETACHED attribute and GC_pthread_create. At the end of the start_function of a thread I use a pthread_cleanup_push to call a function that change a flag in a struct, and than a pthread_cleanup_pop(1).
The last instruction is a pthread_exit because for some reason normal return doesn't free used memory for the thread and program stop sometimes with "Abort: too many threads" (I don't know if this is a problem of the colletor ... I'm not expert on threads ... so I put this call as last instruction). I'm sure that process reach GC_thread_exit_proc but at the end there's the Segmentation Fault.
I think GC_thread_exit_proc is the last call performed by the thread, right?
 
 
 
static void cleanupThread(void *thread) {
  ((MyThread*)thread)->flag = THREAD_STATUS_STOP;
}
 
 
 
static void *runThread(void *thread) {
 void *ret;
  
  pthread_cleanup_push(cleanupThread, thread);

  //... do some work. Ret is initialized here
 
  
  /* Call cleanup thread callback function */
  pthread_cleanup_pop(1);
      
  /* On Cygwin exiting without pthread_exit(ret) cause an abort for
     too may threads */
  pthread_exit(ret);
  return ret;
}
 
 
 
 
 
----- Original Message -----
Sent: Tuesday, June 06, 2006 12:53 AM
Subject: RE: [Gc] GC_thread_exit_proc error on win32_threads.c

Can you track this down to a particular instruction that generates the segmentation fault?  This sounds like a possible race in the pthread_cleanup implementation.  Do you use thread cancellation?
 
Hans

From: gc-bounces-o/PNRNCSakrWxDs0y9d3MAC/G2K4zDHf@public.gmane.org [mailto:gc-bounces-o/PNRNCSakrWxDs0y9d3MAC/G2K4zDHf@public.gmane.org] On Behalf Of Tommaso Tagliapietra (EXT VE SYS)
Sent: Monday, May 29, 2006 2:24 AM
To: gc-o/PNRNCSakrWxDs0y9d3MAC/G2K4zDHf@public.gmane.org
Subject: [Gc] GC_thread_exit_proc error on win32_threads.c

In a Pentium4 2.6Ghz with WindowsXP Professional SP2, I have a problem with the release 6.4 of the garbage collector under Cygwin, and probably with other releases of the collector.  It seems that at the end of GC_thread_exit_proc (win32_threads.c module), sometimes my program exit with a Segmentation Fault. I'm sure that there is not my code the problem and probably not the Garbage Collector too. However I've resolved the problem adding a "Sleep(10);" at the end of the function:
 
 
void GC_thread_exit_proc(void *arg)
{
    GC_thread me = (GC_thread)arg;
#   if DEBUG_CYGWIN_THREADS
      GC_printf2("thread 0x%x(0x%x) called pthread_exit().\n",
                 (int)pthread_self(), GetCurrentThreadId());
#   endif
 
    LOCK();
    if (me -> flags & DETACHED) {
      GC_delete_thread(GetCurrentThreadId());
    } else {
      /* deallocate it as part of join */
      me -> flags |= FINISHED;
    }
    UNLOCK();
    Sleep(10);
}
 
 
The same problem doesn't not happen into a P4 2Ghz WindowsXP Professional SP2. Same compiler. Why this stupid change works without segmentation fault? Can be some race conditions the reason?
 
_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Hans Boehm | 6 Jun 16:57 2006
Picon

Re: GC_thread_exit_proc error on win32_threads.c


On Tue, 6 Jun 2006, Tommaso Tagliapietra (EXT VE SYS) wrote:

> All threads are created with PTHREAD_CREATE_JOINABLE | PTHREAD_CREATE_DETACHED attribute and
GC_pthread_create. At the end of the start_function of a thread I use a pthread_cleanup_push to call a
function that change a flag in a struct, and than a pthread_cleanup_pop(1).
Don't do that.  PTHREAD_CREATE_JOINABLE means that the thread data
structure will persists after the thread finishes, and has to be
explicitly deallocated with pthread_join.  PTHREAD_CREATE_DETACHED
means it won't persists, and hence the thread can't be joined.  You can't
have it both ways.

Hans
Picon

Re: GC_thread_exit_proc error on win32_threads.c

However never of my threads are joined. Can be the attribute the problem?

Tommy

----- Original Message ----- 
From: "Hans Boehm" <Hans.Boehm@...>
To: "Tommaso Tagliapietra (EXT VE SYS)" <tommaso.tagliapietra@...>
Cc: "Boehm, Hans" <hans.boehm@...>; <gc@...>
Sent: Tuesday, June 06, 2006 4:57 PM
Subject: Re: [Gc] GC_thread_exit_proc error on win32_threads.c

>
>
> On Tue, 6 Jun 2006, Tommaso Tagliapietra (EXT VE SYS) wrote:
>
>> All threads are created with PTHREAD_CREATE_JOINABLE | 
>> PTHREAD_CREATE_DETACHED attribute and GC_pthread_create. At the end of 
>> the start_function of a thread I use a pthread_cleanup_push to call a 
>> function that change a flag in a struct, and than a 
>> pthread_cleanup_pop(1).
> Don't do that.  PTHREAD_CREATE_JOINABLE means that the thread data
> structure will persists after the thread finishes, and has to be
> explicitly deallocated with pthread_join.  PTHREAD_CREATE_DETACHED
> means it won't persists, and hence the thread can't be joined.  You can't
> have it both ways.
>
> Hans
> 
Boehm, Hans | 6 Jun 19:07 2006
Picon

RE: GC_thread_exit_proc error on win32_threads.c

In that case, they should be created with just PTHREAD_CREATE_DETACHED.
I don't know what the impact of that would be without looking at the
pthreads implementation.  I would fix that and see if the problem goes
away.

Hans 

> -----Original Message-----
> From: Tommaso Tagliapietra (EXT VE SYS) 
> [mailto:tommaso.tagliapietra@...] 
> Sent: Tuesday, June 06, 2006 8:08 AM
> To: Boehm, Hans
> Cc: Boehm, Hans; gc@...
> Subject: Re: [Gc] GC_thread_exit_proc error on win32_threads.c
> 
> However never of my threads are joined. Can be the attribute 
> the problem?
> 
> Tommy
> 
> 
> ----- Original Message -----
> From: "Hans Boehm" <Hans.Boehm@...>
> To: "Tommaso Tagliapietra (EXT VE SYS)" <tommaso.tagliapietra@...>
> Cc: "Boehm, Hans" <hans.boehm@...>; <gc@...>
> Sent: Tuesday, June 06, 2006 4:57 PM
> Subject: Re: [Gc] GC_thread_exit_proc error on win32_threads.c
> 
> 
> >
> >
> > On Tue, 6 Jun 2006, Tommaso Tagliapietra (EXT VE SYS) wrote:
> >
> >> All threads are created with PTHREAD_CREATE_JOINABLE | 
> >> PTHREAD_CREATE_DETACHED attribute and GC_pthread_create. 
> At the end of 
> >> the start_function of a thread I use a 
> pthread_cleanup_push to call a 
> >> function that change a flag in a struct, and than a 
> >> pthread_cleanup_pop(1).
> > Don't do that.  PTHREAD_CREATE_JOINABLE means that the thread data
> > structure will persists after the thread finishes, and has to be
> > explicitly deallocated with pthread_join.  PTHREAD_CREATE_DETACHED
> > means it won't persists, and hence the thread can't be 
> joined.  You can't
> > have it both ways.
> >
> > Hans
> > 
> 
> 
Hans Boehm | 7 Jun 07:40 2006
Picon

Re: gc for GNU/kFreeBSD

Thanks.  And sorry again for the delay.

It looks fine to me.  I put it into my 6.8 tree and the 7.0 CVS tree.
The only potnetial issue is that it required some hand editing since
it conflicted with previous DragonFly changes.  Hopefully I didn't
add any typos.

Hans

On Thu, 18 May 2006, Petr Salinger wrote:

> Hello.
>
> I tried to build gc 6.7 for GNU/kFreeBSD.
> Basically it is FreeBSD kernel and glibc+linuxthreads
> in userspace, see http://glibc-bsd.alioth.debian.org/doc/intro.html.
>
> Would be possible to add support via attached patch.
> It adds only detection logic into setup.
>
> Thanks for considering it.
>
> Petr
>
> ------------------------------------------------------------------
> After relibtoolizing with newer libtool - results of "make check":
>
> Completed 3 tests
> Allocated 5716965 collectable objects
> Allocated 306 uncollectable objects
> Allocated 3750000 atomic objects
> Allocated 34440 stubborn objects
> Finalized 6604/6604 objects - finalization is probably ok
> Total number of bytes allocated is 278819732
> Final heap size is 9826304 bytes
> Collector appears to work
> Completed 212 collections
> PASS: gctest
> usage: test_cpp number-of-iterations
> Assuming 10 iters
> Starting iteration 1
> Starting iteration 2
> Starting iteration 3
> Starting iteration 4
> Starting iteration 5
> Starting iteration 6
> Starting iteration 7
> Starting iteration 8
> Starting iteration 9
> Starting iteration 10
> The test appears to have succeeded.
> PASS: test_cpp
> ==================
> All 2 tests passed
> ==================
Picon

Re: GC_thread_exit_proc error on win32_threads.c

Another question on gc6.7: there is a reason why in win32_threads.c at the 
end of GC_start_routine there is a

    pthread_cleanup_pop(0);

and in pthread_support.c  there is a

    pthread_cleaunp_pop(1);

?

thank you for the other answers.

Tommy

----- Original Message ----- 
From: "Boehm, Hans" <hans.boehm@...>
To: "Tommaso Tagliapietra (EXT VE SYS)" <tommaso.tagliapietra@...>
Cc: <gc@...>
Sent: Tuesday, June 06, 2006 7:07 PM
Subject: RE: [Gc] GC_thread_exit_proc error on win32_threads.c

In that case, they should be created with just PTHREAD_CREATE_DETACHED.
I don't know what the impact of that would be without looking at the
pthreads implementation.  I would fix that and see if the problem goes
away.

Hans

> -----Original Message-----
> From: Tommaso Tagliapietra (EXT VE SYS)
> [mailto:tommaso.tagliapietra@...]
> Sent: Tuesday, June 06, 2006 8:08 AM
> To: Boehm, Hans
> Cc: Boehm, Hans; gc@...
> Subject: Re: [Gc] GC_thread_exit_proc error on win32_threads.c
>
> However never of my threads are joined. Can be the attribute
> the problem?
>
> Tommy
>
>
> ----- Original Message -----
> From: "Hans Boehm" <Hans.Boehm@...>
> To: "Tommaso Tagliapietra (EXT VE SYS)" <tommaso.tagliapietra@...>
> Cc: "Boehm, Hans" <hans.boehm@...>; <gc@...>
> Sent: Tuesday, June 06, 2006 4:57 PM
> Subject: Re: [Gc] GC_thread_exit_proc error on win32_threads.c
>
>
> >
> >
> > On Tue, 6 Jun 2006, Tommaso Tagliapietra (EXT VE SYS) wrote:
> >
> >> All threads are created with PTHREAD_CREATE_JOINABLE |
> >> PTHREAD_CREATE_DETACHED attribute and GC_pthread_create.
> At the end of
> >> the start_function of a thread I use a
> pthread_cleanup_push to call a
> >> function that change a flag in a struct, and than a
> >> pthread_cleanup_pop(1).
> > Don't do that.  PTHREAD_CREATE_JOINABLE means that the thread data
> > structure will persists after the thread finishes, and has to be
> > explicitly deallocated with pthread_join.  PTHREAD_CREATE_DETACHED
> > means it won't persists, and hence the thread can't be
> joined.  You can't
> > have it both ways.
> >
> > Hans
> >
>
>

Gmane