Skip to content

introduce Transaction variables (STM support) - #3652

Closed
ko1 wants to merge 1 commit into
ruby:masterfrom
ko1:thread_tvar
Closed

introduce Transaction variables (STM support)#3652
ko1 wants to merge 1 commit into
ruby:masterfrom
ko1:thread_tvar

Conversation

@ko1

@ko1 ko1 commented Oct 12, 2020

Copy link
Copy Markdown
Contributor

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

ko1 commented Oct 29, 2020

Copy link
Copy Markdown
Contributor Author

rejected to introduce it into core now.

@ko1 ko1 closed this Oct 29, 2020
@jasonwbarnett

Copy link
Copy Markdown

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

@ko1

ko1 commented Oct 30, 2020

Copy link
Copy Markdown
Contributor Author

Yes.

@eregon

eregon commented Oct 31, 2020

Copy link
Copy Markdown
Member

@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

ko1 commented Oct 31, 2020

Copy link
Copy Markdown
Contributor Author

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants