[gambit-list] Apple's code for Grand Central Station

Christian Jaeger chrjae at gmail.com
Sat Sep 12 23:13:35 EDT 2009


Hello Brad

I'm summarizing my understanding of "Grand Central Station" at the end
of this mail [*], for the possibly benefit to others or as a base for
detailed discussion or corrections if I'm missing something.

To me it seems the most immediate usefulness of Apple's library for
Gambit may be in the FFI, to move blocking procedure calls off the
Gambit VM system thread in an efficient way (more efficient than with
the pipe based approach; although I'm not sure there's another
solution than a pipe for the backward communication of the results).

Whether parts of the library can be useful for an SMP implementation
of the VM: maybe the queue implementation? Relying on the "blocks"
implementation is probably not in the interest of portability.

Since I don't have OS X: has anyone gotten anything to run under Linux?

Christian.

[*]
"Grand Central Station" seems to be, in my words:

(1) a modification to the GCC (only llvm-gcc?) and clang compilers to
add closure support to C/C++/ObjC, with captured bindings being
read-only by default (for some reason unknown to me they call them
"blocks")

(2) an efficient lockless SMP safe queue implementation, used to send
data to other OS threads (aka mailbox)

(3) an api/spec to use the queues for sending jobs, in the form of the
newly added closures (thunks); there are several queue types, some of
them with guarantees to start the next job only after finishing the
previous one (if I've understood correctly--I guess this will
constrain concurrency, since only one job can run at the same time as
the enqueuer of the job; although if the jobs themselves enqueue other
jobs, maybe it can get to more than a parallelism of 2).

(4) a persistent pool of threads that read jobs from those queues and
run them (somehow respecting the above-mentioned user-specified
serialization wishes)

(5) some mechanism to increase and decrease the number of threads in
the pool to a number optimal for the system. This partly depends on OS
X, but at the same time adapting the pool size may simply not be
necessary on operating systems with more efficient thread
implementations.

The whole thing seems meant to deal with short-lived jobs (I haven't
seen this mentioned explicitely, but I guess you could disrupt the
parallel processing if you push a couple jobs that never finish,
although maybe they will increase the number of OS threads in the pool
to accomodate for the never-ending threas). The idea is to avoid the
overhead of creation and termination of a new OS thread for each job.



More information about the Gambit-list mailing list