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.
Afficher les réponses par date