[ruby-talk:13371] Re: Native/pthreads in Ruby [Long]

Yukihiro Matsumoto wrote:

> Hi,
>
> In message "[ruby-talk:13224] Re: Native/pthreads in Ruby [Long]"
>     on 01/03/27, Marc Butler <[e-mail]> writes:
>
> |Certainly a global interpreter lock would achieve the synchronization necessary
> |to run the mark-sweep collector.  It seems natural to place this lock in the
> |memory allocation routine, so that only threads that are attempting to allocate
> |memory are locked during garbage collection.
>
> Well, that makes lock granularity much smaller than one giant lock.
> But Ruby internal is not thread safe in general.
>

 True but it releases you from the requirement of having to make all the threads
poll the garbage collector lock at set intervals.  Threads could block on conditions
such as I/O with relative impunity.

>
> |I am curious as to why ruby uses a conservative collector.  I know that Ruby is
> |a type-less language but I would have thought the run time structures used by
> |the interpreter would provide enough information to avoid the need of the
> |collector.  I am only just learning about garbage collection, and have not
> |developed any intuition about such systems.
>
> Well, conservativeness is due to ease of extension writing.  You don't
> have to protect your local C variables in extensions (and builtin
> methods too).

Given that it is not possible to get the stack address from an existing thread.
(Something you pointed out later.)  Would this mean that extension writers would
have to start their threads from a ruby function?  So instead of
pthread_create(...), you might call ruby_native_thread_create(...).

>
>
> |I had imagined that it might be possible to implement a thread oriented
> |collector using the concepts that drive a generational collector.  If we ignore
> |thread recycling for convenience, threads often fall into two categories:
> |short-lived work threads that perform specific tasks; and long-lived threads
> |that handle blocking system calls (like I/O).  By using the thread id like a
> |special reference you can dereference all the data allocated in that threads
> |lifetime, if other threads now have references to that data it will still be
> |safe.
>
> Interesting.  Threads share object space so that objects are not
> belong to any specific thread.  But there might be a solution.

This is certainly true.  However, when a thread calls the allocator it's thread id
is available via pthread_self().  I believe most threading implementations have some
way of retrieving the thread id of the thread.  So you can always mark it as having
been allocated by thread x on the heap.  However mark-sweep is still needed to see
if other threads are consequently referencing it.

>
>
> The other obstacle is pthread does allow retrieving stack address only
> at the creation time.
>
> FYI, Bohem GC wrap pthread_create(), Qscheme using thread signal
> handler to get stack addresses.  OCaml uses assembler code to get
> stack boundary of each invoked C function.
>
>                                                         matz.

Thanks.  It's not always clear where to look for interesting implementations.  Now
if I could just find some time. :)

marc.
--
Apathy: a cynics best friend.
[e-mail]