Re: Gwydion & threads

[address@hidden (Neelakantan Krishnaswami)]

Rob Myers <robmyers@mac.com> wrote:
> On Friday, March 15, 2002, at 12:00 AM, Neelakantan Krishnaswami wrote:
> >
> > What's the problem? Is it the two-word representation of objects?
> > That would make it hard to do assignments atomically, which I think
> > the Dylan threads spec requires.
> 
> Yes, that's the one. IIRC Andreas wrote a threads test that crashed 
> pretty quickly because of this.

It should (warning: WAG) be possible to work around this with this
with a boxing transformation. This would add one indirection to all
variables that use assignment, though. The idea is that if you have
code like this

begin
  let fact = 1;
  for (i = 1 to 5)
    fact := fact * i;
  end for
end;

it becomes

begin
  let fact = ref(1)
  for (i = 1 to 5)
    update(fact, deref(fact) * i)
  end for;
end;

Then, if you use a 1-word representation of reference cells, you can
do assignment "atomically enough". The big downside is that you add an
indirection to *all* mutable variables. That hurts a lot! In this
limited case, it might be done with relatively little performance loss,
though. My idea is to allocate the reference cells on the stack, and
then when you dereference them you can be confident they will be in
cache and not in random bits of memory. This depends a lot on the fact
that references are not user-visible, so that their lifetime is always
the lexical lifetime.

Then the C code might look like:

{
  object factobj = two_words(1), nextval;
  ref fact = &factobj;                   /* ref is a 1-word pointer */
  for (int i = 1, i <= 5; ++i, ) {
    object i_object = two_words(i)
    nextval = multiply(i_object, *fact); /* Non-atomic write to nextval */
    fact = &nextval;                     /* Fact updated atomically */
  }
}

So whenever someone in any thread dereferences fact, it's always
pointing to a valid object. The trouble is that this is only half the
job: I don't know how to how to extend this to update object slots
atomically.


Neel