Opened 12 years ago

Closed 12 years ago

#60 closed defect (fixed)

Thread-safe gf dispatch

Reported by: gz Owned by: gb
Priority: major Milestone:
Component: Runtime (threads, GC) Version:
Keywords: Cc:

Description

It should be possible for gf dispatch to run simultaneously in multiple threads without introducing inconsistencies in CLOS internals (e.g. caches).

FWIW, here's what sbcl does about this: http://lisp-ecoop07.bknr.net/pdf/31662.

Change History (2)

comment:1 Changed 12 years ago by gb

  • Status changed from new to assigned

We clearly need a test case ...

The most obvious way for GF cache update to fail in OpenMCL would seem to be the case where two (or more) class wrappers hash to the same cache index and (because of non-determinacy in the order in which stores from multiple threads might occur) an inconsistent {wrapper, combined-method} pair would be stored in the cache.

Wrappers hash based on a random number assigned to them on creation; giving all wrappers the same hash index might help to provoke collisions and test any means we have of avoiding them.

comment:2 Changed 12 years ago by gb

  • Resolution set to fixed
  • Status changed from assigned to closed

Particular cases where GF-dispatch was known not to be thread-safe were addressed in changeset:7068 (despite the duplicate log comment, changeset:7069 merely removes a few DBG traps in cases where collisions would have occurred.)

If we observe or discover other cases where GF-dispatch is not thread safe, we should open bugs for them.

Note: See TracTickets for help on using tickets.