Which I think makes sense - if txn 1 succeeds and then txn 2 retries before 1 calls rerunPending, 2 shouldn’t be eligible to rerun anyway
I think :joy:
Oleg Pyzhcov
@oleg-py
Well, you might have a different problem with your implementation :D
Tim Spence
@TimWSpence
:joy: Thanks for the help anyway! I made the change to synchronized anyway - it also simplifies the logic as it’s safe to call while you already have the lock. Really struggling to see where the bug is hiding now...
Tim Spence
@TimWSpence
So I found the issue… TimWSpence/cats-stm#21 :joy: Seems like there might be some work to do on fairness - on my machine at least it seems to eventually only run the reindeer but apart from that it seems stable now
@ChristopherDavenport in particular :point_up:
Christopher Davenport
@ChristopherDavenport
Fairness is much better than deadlock.
Tim Spence
@TimWSpence
Agreed!! I’m making a release now so that we have a working release out there
Ross A. Baker
@rossabaker
:tada:
Tim Spence
@TimWSpence
a depressingly simple fix in the end
Christopher Davenport
@ChristopherDavenport
Well removing a succesful transaction seems… reasonable. :smile:
Ross A. Baker
@rossabaker
$1 to remove the line, $9999 to know which one to remove.
Christopher Davenport
@ChristopherDavenport
Note to self: Figure out how to get Ross’s consulting rates.
Tim Spence
@TimWSpence
😂
Ross A. Baker
@rossabaker
That one is often ascribed to Nikola Tesla visiting Henry Ford. Would have been a real good rate back then.
Christopher Davenport
@ChristopherDavenport
That change looks great. So now for transaction fairness. I think the way the problem is designed is that the action is happening on the side so once we always have all the reindeers, it wins via that actions.reduceLeft(_.orElse(_))
The print would need to take longer 0.01 seconds. Going to retry with higher values as it may be a matter of the concurrency rather than the atomicity.
Christopher Davenport
@ChristopherDavenport
So I introduced a CS to shift and no change to final behavior.
Christopher Davenport
@ChristopherDavenport
@TimWSpence So how are we doing? I’m still a little worried about our blockage here.
Tim Spence
@TimWSpence
@ChristopherDavenport sorry, haven’t had much time to work on this recently! What did you mean by blockage sorry? I’ve had a bit of a look into retry fairness but haven’t gotten to the bottom of it yet
PS you can see my attempted fix here: TimWSpence/cats-stm@11aef71 I might actually merge this anyway as it seems like the right thing to do - we will now retry transactions that have been waiting longer first. However it still doesn’t seem to fix the behaviour of the Santa Claus problem
Tim Spence
@TimWSpence
Oh sorry, I just re-read your previous comment. I’ll try combining my change above with the one you suggested and see if that fixes it
Christopher Davenport
@ChristopherDavenport
The issue is that without some level of fairness, we are in a position where I cant reliably expect an action that should logically occur to happen.
As in the elves are ready but they are never happening and not because they weren’t waiting. As obviously they were done.
And yes, I agree that lack of fairness is a significant problem :joy:
Tim Spence
@TimWSpence
It think it is fine actually, it just wasn’t what I expected at first. Which leaves me back at square one :sob:
Christopher Davenport
@ChristopherDavenport
Yeah. :cry:
Tim Spence
@TimWSpence
Timer[IO].sleep(n.micros) this shouldn’t block a thread, should it? If I add a 0 to the random int bound then the whole program seems to block sometimes
@ChristopherDavenport good news! After a 7 month sebatical (to be fair, I was on paternity leave for quite a bit of it), I’ve fixed our issues with this :)
(Or at least the Santa Claus example now behaves as expected)
Thanks Ross. Yeah, just bumped the version to get rid of it :joy:
renghen
@renghenKow_twitter
hi
the library is interesting
do you have a java api, so that I can use the lib in kotlin or java
not everyone gets to use scala in thei job
Tim Spence
@TimWSpence
Thanks @renghenKow_twitter The implementation is pretty tied to Scala's cats effect so I think a Java API would be tied to that as well. I'd be surprised if Cats Effect supports Java at all (no implicits or higher kinded types for a start) but @ChristopherDavenport or @rossabaker might be able to give you more details - I've never tried to use it from Java