Give each element a serial number #22

Vectornaut · 2024-11-19T00:14:21Z

Vectornaut commented

2024-11-19 00:14:21 +00:00

Address issue #20 by giving each Element a serial number, which identifies it uniquely (until the serial number wraps around). The serial number assigned by the Element::new constructor.

For future thread-safety, the next serial number is stored in a static atomic variable (assembly::NEXT_ELEMENT_SERIAL), as suggested in this StackOverflow answer. Since the overhead for keeping track of memory ordering should be minimal, we're using the strongest available ordering: sequentially consistent.

Address issue #20 by giving each `Element` a serial number, which identifies it uniquely (until the serial number wraps around). The serial number assigned by the `Element::new` constructor. For future thread-safety, the next serial number is stored in a static atomic variable (`assembly::NEXT_ELEMENT_SERIAL`), as suggested in [this StackOverflow answer](https://stackoverflow.com/a/32936288). Since the overhead for keeping track of memory ordering should be minimal, we're using the strongest available ordering: [sequentially consistent](https://marabos.nl/atomics/memory-ordering.html#seqcst).

Vectornaut added 1 commit 2024-11-19 00:14:22 +00:00

Assign each element a serial number 6b2d44a58c

For future thread-safety, keep the next serial number in a static atomic
variable.

Vectornaut referenced this pull request

2024-11-19 00:16:23 +00:00

Fix element list updates #21

Vectornaut commented

2024-11-19 00:40:59 +00:00

I think the app prototype should be single-threaded for now, so for parsimony we could instead store the next serial number in a thread-local cell, as suggested in this other StackOverflow answer. The thread-local version is ready to go, so let me know which version you'd prefer to review.

I think the app prototype should be single-threaded for now, so for parsimony we could instead store the next serial number in a thread-local cell, as suggested in [this other StackOverflow answer](https://stackoverflow.com/a/32936064). The thread-local version is ready to go, so let me know which version you'd prefer to review.

Vectornaut added 1 commit 2024-11-19 04:30:10 +00:00

Make the next element serial number thread-local 7bc3a9eeae

In the last revision, the next element serial number was thread-safe,
but that might be overdoing it. I suspect that elements will only ever
be created from the main thread.

Vectornaut commented

2024-11-19 04:31:51 +00:00

As discussed over e-mail, we'll go with the thread-local version for now. Ready to review!

Vectornaut added 3 commits 2024-11-22 00:42:56 +00:00

Go back to atomic for next element serial number b0bd31a9da

This reverts commit 7bc3a9eeae.

I'd hoped that `thread_local!` would force our code to be single-
threaded, but apparently it doesn't. With a global mutable static, it
seems like we have to include some kind of thread-safety to avoid
`unsafe` code, and an atomic provides the kind of safety we actually
want.

Add reminder to reconsider global element serials c5f09b99b3

Panic if we run out of serial numbers 133b725053

Vectornaut added 1 commit 2024-11-22 00:47:55 +00:00

Remove caveat about NEXT_ELEMENT_SERIAL wrapping a5fd6545e0

Commit 133b725 should make it impossible for the serial numbers to wrap.

Vectornaut commented

2024-11-22 00:50:08 +00:00

As discussed in our meeting, I've gone back to the atomic version, with one change: we now panic when we run out of serial numbers, rather than silently wrapping around. Ready to review again!