sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<sb0> whitequark, didn't you say that with your counter, the ABA problem would only happen when the counter wraps around? e.g. after ~2**32 erasures
<GitHub> [artiq] sbourdeauducq closed pull request #668: Add experiment repository to experiment PYTHONPATH (master...repo_absolute_imports) https://github.com/m-labs/artiq/pull/668
mumptai_ has joined #m-labs
mumptai has quit [Ping timeout: 258 seconds]
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
<sb0> whitequark, have you documented the print/artiq_compile behavior?
rohitksingh_work has joined #m-labs
sb0 has quit [Quit: Leaving]
klickverbot has quit [Ping timeout: 240 seconds]
Guest67107 has joined #m-labs
Guest67107 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 258 seconds]
rohitksingh_wor1 has quit [Ping timeout: 255 seconds]
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Ping timeout: 258 seconds]
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Ping timeout: 240 seconds]
rohitksingh_work has joined #m-labs
sb0 has quit [Quit: Leaving]
rohitksingh_work has quit [Read error: Connection reset by peer]
<whitequark> sb0: there is no problem with the epoch counter
<whitequark> well, no safety problem
<whitequark> the problem is returning a new value of a user-defined class
Gurty has quit [Quit: Kooll ~o~ datalove <3³\infty]
Gurty has joined #m-labs
Gurty has joined #m-labs
Gurty has quit [Changing host]
rohitksingh has joined #m-labs
sb0 has joined #m-labs
<sb0> whitequark, and what is the problem if you return integers?
<whitequark> ABA problem exactly
<whitequark> hm
<sb0> what problem?
<whitequark> so if I return an integer but want to make it safe, I need to put it in a table somewhere
<whitequark> and then return an index into that table
<whitequark> if an index into that table is returned, then the table is cleared, then filled again, and the index is reused
<whitequark> you silently get a wrong sequence
<sb0> if the index is below the epoch counter then this error is detectable
<sb0> but maybe i misunderstood how the epoch counter is supposed to work
<sb0> I though it worked this way: handles between epoch and epoch+table_length are valid, all other throw exceptions when you try to use them
<sb0> and when you delete a sequence, then epoch is set to epoch+previous_table_length
<sb0> and the tables indices are handle-epoch
<whitequark> epoch is usually a single number, common for all handles
<sb0> yes, it is common for all handles
<whitequark> well you can't retrieve it from a handle
<sb0> with this scheme you only get a wrong sequence if the epoch counter has wrapped, or you have mucked with the integers using non-DMA functions
<sb0> and you never get a crash in any case
<sb0> seems pretty safe to me
<whitequark> that also has a limit on the number of handles
<sb0> no, you can reallocate the table
<whitequark> no
<sb0> just add one layer of indirection
<whitequark> well
<sb0> the kernel CPU fetches a pointer to the table when it plays back
<whitequark> shared mutable memory yet again
<whitequark> can we not do this?
<sb0> then computes an index into it by subtracting the epoch
<whitequark> the epoch and table size need to be communicated back and forth...
<whitequark> I think a better way would be to return a tuple from get_handle(). (epoch, address, advance_mu)
<sb0> yes, shared mutable memory, but it's only mutated while the kernel CPU makes a request for record() or delete() and waits on it
<sb0> not at arbitrary time
<whitequark> that still needs synchronization
<sb0> so it should be fairly easy to manage
<whitequark> it's implicit synchronization, which actually makes the problem worse
<sb0> what problem?
<sb0> theoretical CS problems?
<whitequark> what?
<sb0> if you return the epoch with get_handle(), then it won't invalidate old handles
<sb0> you can do get_handle(), delete(), playback() and it won't detect the problem
<whitequark> sure it will
<whitequark> in fact it will invalidate the old handles better than your solution
<whitequark> (because the probability of clash is fixed at 1/max_value(epoch_counter) and not something depending on how many handles you have)
<sb0> so the kernel cpu maintains its own epoch counter?
<whitequark> just CoreDMA
<sb0> ok, fine
<sb0> then I'm OK with that
<whitequark> no shared mutable memory, no messing with tables...
<whitequark> well it's inelegant because we don't have user-defined value types. but those are annoying.
<sb0> I think it's less safe than what I was proposing, since the addresses are directly exposed, but it's good enough
<whitequark> yes, that bothers me
<sb0> there are many other ways to hose ARTIQ systems anyway
<whitequark> yes
<whitequark> a user can define a syscall for example
<whitequark> that reads from nowhere
<sb0> okay. please go ahead with that tuple solution
fengling has quit [Ping timeout: 252 seconds]
rohitksingh has quit [Quit: Leaving.]
fengling has joined #m-labs
wolfmitchell has quit [Excess Flood]
wolfmitchell has joined #m-labs
klickverbot has joined #m-labs
klickverbot has quit [Ping timeout: 260 seconds]
mumptai_ has quit [Remote host closed the connection]
klickverbot has joined #m-labs