Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

introduce Transaction variables (STM support) #3652

Closed
wants to merge 1 commit into from

Conversation

ko1
Copy link
Contributor

@ko1 ko1 commented Oct 12, 2020

Introduce Thread::TVar and Thread.atomicaly to support transactional
variables (STM: Software Transactional Memory). STM is well known
feature to synchronize shared values and has several advantages
compare with traditional locking mechanisms.

TVar also shared with multiple ractors so you can program shared
state between ractors in transactions.

https://bugs.ruby-lang.org/issues/17261

Introduce Thread::TVar and Thread.atomicaly to support transactional
variables (STM: Software Transactional Memory). STM is well known
feature to synchronize shared values and has several advantages
compare with traditional locking mechanisms.

TVar also shared with multiple ractors so you can program shared
state between ractors in transactions.
@ko1
Copy link
Contributor Author

ko1 commented Oct 29, 2020

rejected to introduce it into core now.

@ko1 ko1 closed this Oct 29, 2020
@jasonwbarnett
Copy link

@ko1 Are you planning to implement in a gem instead?

@ko1
Copy link
Contributor Author

ko1 commented Oct 30, 2020

Yes.

@eregon
Copy link
Member

eregon commented Oct 31, 2020

@ko1 FYI, I found a bug when running with TVar, not sure if it's a Ractor or TVar bug, but the programs needs TVar to run:
chrisseaton/ruby-stm-lee-demo#1

It reproduces with 4f8d9b0 + this commit.
And chrisseaton/ruby-stm-lee-demo@e9ff5c1

$ time N=10 ruby 7-ractor-tvar-lee.rb inputs/testBoard.txt
<internal:ractor>:38: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues.
#<Thread:0x000056443c1f9768 run> terminated with exception (report_on_exception is true):
/home/eregon/code/ruby-stm-lee-demo/lib/lee/adjacent.rb:5:in `point_on_board?': undefined method `x' for 0...75:Range (NoMethodError)
	from /home/eregon/code/ruby-stm-lee-demo/lib/lee/adjacent.rb:25:in `block in adjacent'
	from /home/eregon/code/ruby-stm-lee-demo/lib/lee/adjacent.rb:25:in `select'
	from /home/eregon/code/ruby-stm-lee-demo/lib/lee/adjacent.rb:25:in `adjacent'
	from 7-ractor-tvar-lee.rb:42:in `block (2 levels) in expand'
	from 7-ractor-tvar-lee.rb:40:in `each'
	from 7-ractor-tvar-lee.rb:40:in `block in expand'
	from 7-ractor-tvar-lee.rb:37:in `loop'
	from 7-ractor-tvar-lee.rb:37:in `expand'
	from 7-ractor-tvar-lee.rb:153:in `block (4 levels) in <main>'
	from <internal:thread>:25:in `atomically'
	from 7-ractor-tvar-lee.rb:152:in `block (3 levels) in <main>'
	from 7-ractor-tvar-lee.rb:149:in `loop'
	from 7-ractor-tvar-lee.rb:149:in `block (2 levels) in <main>'

It's a bug, the receiver is always a Point, the Range seems to come from another place on the stack/heap.

I would report to https://bugs.ruby-lang.org/issues/17158, but since this is not merged, I'm not sure what's the right place.

@ko1
Copy link
Contributor Author

ko1 commented Oct 31, 2020

Thank you. I need to check it...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3 participants