Open jswrenn opened 1 year ago
The issue is the loom Cell is being reused across loom runs. Fundamentally, all loom objects must be created in each iteration of the model. This is why switching to a loom thread-local fixes it.
The best we can do is catch this and panic w/ a better error message. Off the top of my head, each iteration of the model could get a unique identifier. Loom objects could then include the iteration identifier and panic if the object's identifier doesn't match the runtime's identifier.
Is this something you want to look into doing?
This seems like an easy enough issue for a new contributor to pick up. I would like to give it a try.
From a cursory glance at the source code, I figured I could try the following:
iteration_id
field to rt::execution::Execution
Builder::check(...)
increment this iteration_id
after each iterationrt::Cell::new(...)
read the iteration_id
from the supplied execution, and store it in the Cell
Cell::start_read(...)
and Cell::start_write(...)
check that the stored iteration_id
matches the current executionrt
or others, too?).Does this seem like a reasonable approach?
Actually, the Execution
object already has an id, which is already unique for each iteration (it is modified in Execution::step()
), so we need only add code to the objects to track this existing id.
The following program:
...panics with:
The issue does not occur if
loom::thread_local!
(but unfortunately it took me several days to realize that loom even provided a mocked version ofthread_local!
and that I might want to use it).