Hi Michael, Just a quick note to indicate that, personally, I'd be most interested in the multithreading part.
Actually, is the strategy you're pursueing atm a well-known one? Or did you come up with it yourself for the particular COLA object model? Cheers, Hans On Friday 25 January 2008, Michael FIG wrote: > Hi, all... > > I've been testing the following COLA patches for the past few weeks, > and want to know if anybody's interested in development along these > lines. Feedback would be good, because that will help determine where > I put my energy. > > You can find instructions on how to download and install these > unofficial patches from: http://vpri.org/fonc_wiki/index.php/Sources > > Here are the patch names (in dependency order), and their > descriptions: > > libjolt-fixups.patch: Get libjolt working again. > > mercurize.patch: Add Mercurial infrastructure. > > makefile.patch: Build environment enhancements. > > doc-fixes.patch: Documentation fixes. > > gcc-is-picky.patch: Fix errors caused by picky compilers (notably late > 3.x GCC). > > friendly-make.patch: Update Makefiles to be more friendly. > > explicit-precedence.patch: Enforce explicit operator precedence around > math-like selectors. > > jolt-libid-primitive.patch: Export only _libid as a Jolt primitive. > > message-send-descriptors.patch: Change ABI to use __send structures. > > send-argument_count.patch: Add #argument_count to the idc-generated > send structure. > > thread-objects.patch: Create per-thread objects that hang off of > struct __send to store thread-specific data. > > dynamic-closure.patch: Define (dynamic-closure ...) to allow Jolt to > create dynamically-scoped BlockClosures. > > per-object-metadata.patch: Add a new meta object before the vtable. > > multithreading-madness.patch (work in progress): Implement threading > in a Jolt test program by dynamically installing a read-write lock in > each object, and updating the _libid multithreading primitives for > pthreads. > > I'll probably break the multithreading-madness.patch up into smaller > pieces: one for the object trace mechanism (which works, but is not > yet complete), one for a pthreads-only test, and one for a windows > threading test. A nice side-effect of the object trace mechanism is > that it may lay the foundation for precise GC in the future. > > The multithreading patch uses lock-free algorithms for all the libid.c > reads (such as _vtable lookups), and per-object write locks for > updates. By also putting the method cache in the per-thread object, > I'm hoping that the most heavily-used code (namely > _libid->bind) won't be a bottleneck. > > The main reason I'm working on multithreading-madness is that there > was a comment on Lambda the Ultimate which suggested that COLA would > only be appropriate for single-threaded programming. I'm wanting to > add these features sooner rather than later so that they will mature > alongside the compiler (since, as we all know, Threads Cannot Be > Implemented As A Library(TM)). > > Have fun! -- If we cannot live so as to be happy, let us at least live so as to deserve it -- Immanuel Hermann Fichte A liberal is a person whose interests aren't at stake at the moment -- Willis Player Ark Linux - Linux for the Masses (http://arklinux.org) Hans Schippers Aspirant FWO - Vlaanderen Formal Techniques in Software Engineering (FoTS) University of Antwerp Middelheimlaan 1 2020 Antwerpen - Belgium Phone: +32 3 265 38 71 Fax: +32 3 265 37 77 _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
