60. EPMO Open Source Coordination Office Redaction File Detail Report

Produced by Araxis Merge on 5/24/2018 2:23:48 PM Central Daylight Time. See www.araxis.com for information about Merge. This report uses XHTML and CSS2, and is best viewed with a modern standards-compliant browser. For optimum results when printing this report, use landscape orientation and enable printing of background images and colours in your browser.

60.1 Files compared

#	Location	File	Last Modified
1	CUI-v2.5.0-release-source.zip\public\fake_docstore	2016_rubykaigi.pdf	Fri Mar 23 17:02:06 2018 UTC
2	CUI-v2.5.0-release-source.zip\public\fake_docstore	2016_rubykaigi.pdf	Wed May 16 15:48:39 2018 UTC

60.2 Comparison summary

Description	Between Files 1 and 2
Description	Text Blocks	Lines
Unchanged	1	1808
Changed	0	0
Inserted	0	0
Removed	0	0

60.3 Comparison options

Whitespace
Character case	Differences in character case are significant
Line endings	Differences in line endings (`CR` and `LF` characters) are ignored
CR/LF characters	Not shown in the comparison detail

60.4 Active regular expressions

No regular expressions were active.

60.5 Comparison detail

	1	A proposal of
	2	new concur rency mode l
	3	for Ruby 3
	4	Koichi Sas ada
	5	ko1@heroku .com
	6	People lov e “Concurr ency”
	7	Concurrent
	8	RubyKaigi
	9	(at least, there are two
	10	parallel s essions)
	11	Why people love (to discuss)
	12	“Concurren cy”?
	13	•Performan ce by “Par allel” exe cution to utilize
	14	multiple-c ores
	15	•Ruby has thread sys tem, but M RI doesn’t permit
	16	to allow p arallel ex ecution.
	17	About this presentat ion
	18	•Show “Why difficult multi-thr eads progr ams”
	19	•Propose n ew concurr ent and pa rallel mec hanism
	20	idea named “Guild”
	21	• For Ruby 3
	22	Koichi Sas ada
	23	•A program mer living in Tokyo, Japan
	24	•Ruby core committer since 200 7
	25	•YARV, Fib er, … (Rub y 1.9)
	26	•RGenGC, R incGC (Rub y 2…)
	27	Koichi is an Employe e
	28	Difficulty of
	29	Multi-thre ads progra mming
	30	Programmin g language evolution
	31	•Trade-off : Performa nce v.s. S afety/Easi ly
	32	•Performan ce: making faster pr ograms
	33	• Safety: making bug -free prog rams
	34	• Easily: making pro grams with small eff orts
	35	Two exampl e
	36	C language
	37	•String ma nipulation with poin ters
	38	•Memory ma nagement w ithout GC
	39	String man ipulation with point ers
	40	•C: Using raw pointe rs to mani pulate str ings
	41	•Good: all -purpose a nd fast
	42	•Bad: Erro r-prone
	43	• Generate s strange behavior, such as ab normal ter mination
	44	•Ruby: Wra p with Str ing class
	45	•Good: Eas y to use
	46	•Bad: slow er than C in some ca ses
	47	Object man agement wi thout GC
	48	•C: Free m emory obje cts manual ly
	49	•Good: ful l control (target, t iming and so on)
	50	•Bad: Erro r-prone
	51	• double-f ree/memory -leak, …
	52	•Ruby: Aut omatic col lection wi th GC
	53	•Good: not hing to ca re about o bject coll ection
	54	•Bad: intr oduce some overhead
	55	Ruby chose “safety/e asily” app roach
	56	•Ruby enco urage “Hap py Program ming”
	57	•Reduce pr ogrammer’s cost
	58	•Nowadays computer i s enough f aster
	59	•Implement ation tech niques ove rcome
	60	performanc e penaltie s
	61	Do you wan t to progr am without GC?
	62	Difficult to make
	63	correct (b ug-free)
	64	programs
	65	Muilti-thr eads progr amming is difficult
	66	• Introduc e data rac e, race co ndition
	67	• Introduc e deadlock , livelock
	68	•Difficult y on debug ging becau se of
	69	nondetermi nistic beh avior
	70	•difficult to reprod uce same p roblem
	71	•Difficult to tune p erformance
	72	Difficult to make
	73	fast progr ams
	74	Data race and race c ondition
	75	•Bank amou nt transfe r example
	76	•Quoted fr om Race Co ndition vs . Data Rac e
	77	http://blo g.regehr.o rg/archive s/490
	78	def transf er1 (amoun t, account _from, acc ount_to)
	79	if (accoun t_from.bal ance < amo unt) retur n NOPE
	80	account_to .balance + = amount
	81	account_fr om.balance -= amount
	82	return YEP
	83	end
	84	Data race
	85	•“account_ to.balance += amount ” has Data -race
	86	• Assume t wo threads (T1 and T 2) invoke this metho ds with
	87	same bank accounts
	88	# interlea ve two thr eads (T1: amount = 1 00, T2: am ount = 200 )
	89	T1: t1 = a ccount_to. balance # t1 = 10
	90	T2: t2 = a ccount_to. balance # t2 = 10
	91	T2: accoun t_to.balan ce = t2 + 200 #=> 21 0
	92	T1: accoun t_to.balan ce = t1 + 100 #=> 11 0 (expecte d: 310)
	93	Race condi tion
	94	•To avoid data-race with the l ock
	95	•But there is anothe r problem yet
	96	# Lock wit h “Thread. exclusive”
	97	def transf er2 (amoun t, account _from, acc ount_to)
	98	if (accoun t_from.bal ance < amo unt) retur n NOPE
	99	Thread.exc lusive{ ac count_to.b alance += amount }
	100	Thread.exc lusive{ ac count_from .balance - = amount }
	101	return YEP
	102	end
	103	Race condi tion
	104	•To avoid data-race with the l ock
	105	•But there is anothe r problem yet
	106	# T1 amoun t = 100, T 2 amount = 200, acco unt_from.b alance = 2 50
	107	T1: if (ac count_from .balance ( == 250) < 100) retur n NOPE # O K, go thro ugh
	108	T2: if (ac count_from .balance ( == 250) < 200) retur n NOPE
	109	T2: Threa d.exclusiv e{ account _to.balanc e += 200 }
	110	T2: Threa d.exclusiv e{ account _from.bala nce -= 200 } #=> 250 -200 => 50
	111	T1: Threa d.exclusiv e{ account _to.balanc e += 100 }
	112	T1: Threa d.exclusiv e{ account _from.bala nce -= 100 } #=> 50 - 100 => n egative nu mber!!
	113	Final solu tion
	114	•Lock whol e of metho d
	115	def transf er1 (amoun t, account _from, acc ount_to)
	116	Thread.exc lusive{
	117	if (accoun t_from.bal ance < amo unt) retur n NOPE
	118	account_to .balance + = amount
	119	account_fr om.balance -= amount
	120	return YEP
	121	}
	122	end
	123	Another ex ample
	124	Multi-thre ad quiz
	125	•What happ en on this program?
	126	ary = [1, 2, 3]
	127	t1 = Threa d.new{
	128	ary.concat [4, 5, 6]
	129	}
	130	t2 = Threa d.new{
	131	p ary # wh at’s happe n?
	132	}.join
	133	(1) [1, 2, 3]
	134	(2) [1, 2, 3, 4, 5, 6]
	135	(3) (1) or (2)
	136	Another ex ample
	137	Multi-thre ad quiz
	138	•Answer: ( 4) depends on an int erpreter
	139	ary = [1, 2, 3]
	140	t1 = Threa d.new{
	141	ary.concat [4, 5, 6]
	142	}
	143	t2 = Threa d.new{
	144	p ary # wh at’s happe n?
	145	}.join
	146	On MRI, (3 ) is corre ct
	147	It will sh ows
	148	[1, 2, 3] or
	149	[1, 2, 3, 4, 5, 6]
	150	(depends o n thread
	151	switching timing)
	152	Another ex ample
	153	Multi-thre ad quiz
	154	•Answer: ( 4) depends on an int erpreter
	155	ary = [1, 2, 3]
	156	t1 = Threa d.new{
	157	ary.concat [4, 5, 6]
	158	}
	159	t2 = Threa d.new{
	160	p ary # wh at’s happe n?
	161	}.join
	162	On JRuby:
	163	It can cau se Java
	164	exception because
	165	“Array#con cat” is no t
	166	thread saf e
	167	On JRuby …
	168	# similar program
	169	h = Hash.n ew(0)
	170	NA = 1_000
	171	10_000.tim es{
	172	ary = []
	173	(1..10).ea ch{
	174	Thread.new {
	175	NA.times{\| i\|
	176	ary.concat [i]
	177	}
	178	}
	179	}
	180	t2 = Threa d.new{
	181	s = ary.du p
	182	}.join
	183	}
	184	Unhandled Java excep tion: java .lang.Null PointerExc eption
	185	java.lang. NullPointe rException : null
	186	rbInspect at org/jru by/RubyBas icObject.j ava:1105
	187	inspect at org/jruby /RubyObjec t.java:516
	188	inspectAry at org/jr uby/RubyAr ray.java:1 469
	189	inspect at org/jruby /RubyArray .java:1497
	190	cacheAndCa ll at org/ jruby/runt ime/callsi te/Caching CallSite.j ava:293
	191	call at or g/jruby/ru ntime/call site/Cachi ngCallSite .java:131
	192	block in t .rb at t.r b:17
	193	yieldDirec t at org/j ruby/runti me/Compile dIRBlockBo dy.java:15 6
	194	yieldSpeci fic at org /jruby/run time/IRBlo ckBody.jav a:73
	195	yieldSpeci fic at org /jruby/run time/Block .java:136
	196	times at o rg/jruby/R ubyFixnum. java:291
	197	cacheAndCa ll at org/ jruby/runt ime/callsi te/Caching CallSite.j ava:303
	198	callBlock at org/jru by/runtime /callsite/ CachingCal lSite.java :141
	199	call at or g/jruby/ru ntime/call site/Cachi ngCallSite .java:145
	200	<top> at t .rb:3
	201	invokeWith Arguments at java/la ng/invoke/ MethodHand le.java:59 9
	202	load at or g/jruby/ir /Compiler. java:111
	203	runScript at org/jru by/Ruby.ja va:833
	204	runScript at org/jru by/Ruby.ja va:825
	205	runNormall y at org/j ruby/Ruby. java:760
	206	runFromMai n at org/j ruby/Ruby. java:579
	207	doRunFromM ain at org /jruby/Mai n.java:425
	208	internalRu n at org/j ruby/Main. java:313
	209	run at org /jruby/Mai n.java:242
	210	main at or g/jruby/Ma in.java:20 4
	211	jruby 9.1. 2.0 (2.3.0 ) 2016-05- 26 7357c8f OpenJDK 6 4-Bit Serv er VM 24.9 5-b01 on 1 .7.0_101-b 00 +jit [l inux-x86_6 4]
	212	On 8 hardw are thread s machine
	213	Difficulty of multi- threads pr ograms
	214	•We need t o synchron ize all sh aring muta ble
	215	objects co rrectly
	216	•We need t o know whi ch methods are threa d-safe.
	217	• Easy to track all on small p rogram
	218	•Difficult to track on big pro grams, esp ecially on
	219	programs u sing gems
	220	•We need t o check al l of sourc e codes, o r believe
	221	library do cuments (b ut documen ts should be correct )
	222	•Multi-thr eads prog. requires “completen ess”
	223	Difficulty of multi- threads pr ograms (co nt.)
	224	•For debug ging, it i s difficul t to find out the bu gs
	225	•Backtrace may not w ork well b ecause the problem
	226	may be pla ced on ano ther line.
	227	•Bugs don’ t appear f requently with small data
	228	•Difficult to reprod uce issues because o f
	229	nondetermi nistic beh avior
	230	FYI:
	231	Why MRI Ar ray#concat is thread -safe?
	232	•MRI uses GVL (Giant /Global VM Lock) to control
	233	thread swi tching tim ing and C methods (s uch as
	234	Array#conc at) are wo rking atom ically.
	235	•GVL prohi bits paral lel thread execution (BAD),
	236	however it avoids se veral seve re issues (GOOD).
	237	Thread pro gramming:
	238	Performanc e tuning i ssue
	239	a1 = []; a 2 = []
	240	NA = 10_00 0_000
	241	t1 = Threa d.new{
	242	NA.times{\| i\| a1 << i }
	243	}.join
	244	t2 = Threa d.new{
	245	NA.times{\| i\| a2 << i }
	246	}.join
	247	Serial pro gram:
	248	real 0m 8.568s
	249	user 0m 37.816s
	250	sys 0m 5.530s
	251	on JRuby
	252	Thread pro gramming:
	253	Performanc e tuning i ssue
	254	a1 = []; a 2 = []
	255	NA = 10_00 0_000
	256	t1 = Threa d.new{
	257	NA.times{\| i\| a1 << i }
	258	}
	259	t2 = Threa d.new{
	260	NA.times{\| i\| a2 << i }
	261	}
	262	t1.join; t 2.join
	263	Parallel p rogram
	264	(2 threads ):
	265	real 0m 6.411s
	266	user 0m 20.527s
	267	sys 0m 7.798s
	268	Thread pro gramming:
	269	Performanc e tuning i ssue
	270	a1 = []; a 2 = []
	271	NA = 10_00 0_000
	272	m1, m2 = Mutex.new, Mutex.new
	273	t1 = Threa d.new{
	274	NA.times{\| i\| m1.sync hronize{ a 1 << i }}
	275	}
	276	t2 = Threa d.new{
	277	NA.times{\| i\| m2.sync hronize{ a 2 << i }}
	278	}
	279	t1.join; t 2.join
	280	Parallel p rogram wit h
	281	a useless lock 1
	282	(2 threads ):
	283	real 0m 10.264s
	284	user 0m 38.370s
	285	sys 0m 4.406s
	286	Thread pro gramming:
	287	Performanc e tuning i ssue
	288	a1 = []; a 2 = []
	289	NA = 10_00 0_000
	290	m = Mutex. new
	291	t1 = Threa d.new{
	292	NA.times{\| i\| m.synch ronize{ a1 << i }}
	293	}
	294	t2 = Threa d.new{
	295	NA.times{\| i\| m.synch ronize{ a2 << i }}
	296	}
	297	t1.join; t 2.join
	298	Parallel p rogram wit h
	299	a useless lock 2
	300	(2 threads ):
	301	real 0m 15.163s
	302	user 0m 45.317s
	303	sys 0m 9.658s
	304	Performanc e tuning i ssue
	305	Execution time
	306	Serial pro gram 8.568 s
	307	Parallel p rogram 6.4 11s
	308	Parallel p rogram wit h a
	309	useless lo ck 1
	310	10.264s
	311	Parallel p rogram wit h a
	312	useless lo ck 2
	313	15.163s
	314	Thread pro gramming:
	315	Performanc e tuning i ssue
	316	We need to use just correct nu mber locks
	317	Not enough → unexpec ted behavi or
	318	Too much → performan ce penalty
	319	FYI: synch ronization mechanism
	320	•Many sync hronizatio n mechanis ms…
	321	•Mutual ex clusion (M utex), mon itor, crit ical secti on
	322	• Transact ional memo ry (optimi stic lock)
	323	•Atomic in structions
	324	• Synchron ized Queue
	325	•…
	326	•Research on many li ghtweight lock algor ithms
	327	•They assu me we can use them c orrectly
	328	Overcome t hread diff iculty
	329	Key idea
	330	Problem:
	331	Easy to sh are mutabl e objects
	332	Idea:
	333	Do not all ow to shar e mutable objects
	334	without an y restrict ion
	335	Study from other lan guages
	336	•Shell scr ipt with p ipes, Rack et (Place)
	337	•Copy muta ble data b etween pro cesses w/ pipes
	338	•Erlang/El ixir
	339	•Do not al low mutabl e data
	340	•Clojure
	341	•Basically do not al low mutabl e data
	342	• Special data struc ture to sh are mutabl e objects
	343	•Note that it can sh are mutabl e objects on Java la yer
	344	NOTE: we d o not list approache s using “t ype system ”
	345	Don’t you know
	346	Elixir lan guage?
	347	Programmin g Elixir 1 .2
	348	by Dave Th omas
	349	邦訳：プログラミング Elixir
	350	笹田耕一・鳥井雪共訳 2016/08/1 9
	351	You can bu y it TODAY !!
	352	サイン会は明日13時らしいです
	353	Summary of approache s
	354	•Communica tion with copied dat a (shell s cripts)
	355	• Good: we don’t nee d locks
	356	• Bad: cop y everythi ng is slow
	357	•Prohibit mutable ob jects
	358	• Good: we don’t nee d locks
	359	• Bad: Rub y utilizes many “wri te” operat ions. Unac ceptable.
	360	•Provide s pecial dat a structur e to share mutable o bjects
	361	• Good: we don’t nee d locks (w ho don’t u se such sp ecial data
	362	structures )
	363	• Bad: Dif ficult to use specia l data str uctures.
	364	Background was finis hed
	365	Our goal f or Ruby 3
	366	•We need t o keep com patibility with Ruby 2.
	367	•We can ma ke paralle l program.
	368	•We should n’t consid er about l ocks any m ore.
	369	•We can sh are object s with cop y, but cop y
	370	operation should be fast.
	371	•We should share obj ects if we can.
	372	•We can pr ovide spec ial object s to share mutable
	373	objects li ke Clojure if we rea lly need s peed.
	374	“Guild”
	375	New concur rency mode l for Ruby 3
	376	Guild: New concurren cy abstrac tion
	377	•Guild has at least one thread (and a th read has
	378	at least o ne fiber)
	379	Guild
	380	Thread
	381	Fiber
	382	Guild
	383	Thread
	384	Fiber
	385	Guild
	386	Thread
	387	Fiber
	388	Fiber
	389	Thread
	390	Fiber
	391	Threads in different guilds ca n run in
	392	Parallel
	393	• Threads in differe nt guilds can run in parallel
	394	• Threads in a same guild can not run in parallel
	395	because of GVL (or G GL: Giant Guild Lock )
	396	G1:T1
	397	G1:T2
	398	G2:T3
	399	Acquire GG L
	400	Acquire GG L
	401	Guild and objects:
	402	All object s have the ir own mem bership
	403	•All of mu table obje cts should belong to only one
	404	Guild (all mutable o bjects are member of one guild )
	405	•Other gui lds can no t access o bjects
	406	Guild 1 Gu ild 2
	407	obj
	408	obj
	409	obj
	410	obj
	411	obj
	412	Can’t acce ss
	413	(read/writ e)
	414	NG!!
	415	Object mem bership
	416	Only one g uild can a ccess muta ble object
	417	→ We don’t need to c onsider ab out locks
	418	Because:
	419	NO data ra ces and NO race cond itions
	420	(if all gu ilds use o nly one th read)
	421	Inter guil ds communi cation
	422	•“Guild::C hannel” to communica te each gu ilds
	423	•Two commu nication m ethods
	424	1. Copy
	425	2. Transfe r membersh ip or Move in short
	426	Copy using Channel
	427	•Guild::Ch annel#tran sfer(obj) send deep copied
	428	object(s) to a desti nation gui ld.
	429	•dRuby and multi-pro cess syste m use this kind of
	430	communicat ion
	431	Copy using Channel
	432	Guild1 Gui ld2
	433	o2
	434	o3
	435	o1
	436	channel
	437	o2
	438	o3
	439	o1
	440	COPY
	441	channel.tr ansfer(o1) o1 = chan nel.receiv e
	442	O2:Data
	443	O3:Data
	444	O2:Data
	445	O3:Data
	446	Move using Channel
	447	[New techn ique!!]
	448	•Guild::Ch annel#tran sfer_membe rship(obj) change
	449	the member ship of ob ject(s)
	450	• Leave fr om the sou rce guild
	451	• Join to the destin ation guil d
	452	•Prohibit accessing to left ob jects
	453	• Cause ex ceptions a nd so on
	454	• ex) obj = “foo”
	455	ch.transfe r_membersh ip(obj)
	456	obj.upcase #=> Error !!
	457	p(obj) #=> Error!!
	458	Move using Channel
	459	Guild1 Gui ld2
	460	o2
	461	o3
	462	o1
	463	channel
	464	MOVE
	465	channel.tr ansfer_mem bership(o1 ) o1 = cha nnel.recei ve
	466	O2:Data
	467	O3:Data
	468	Move using Channel
	469	Guild1 Gui ld2
	470	channel
	471	o2
	472	o3
	473	o1
	474	MOVE
	475	channel.tr ansfer_mem bership(o1 ) o1 = cha nnel.recei ve
	476	O2:Data
	477	O3:Data
	478	-
	479	-
	480	-
	481	From Guild 1 perspect ive,
	482	transferre d objects are invali dated
	483	Sharing im mutable ob jects
	484	• Immutabl e objects can be sha red with a ny
	485	guilds
	486	• a1 = [1, 2, 3].fre eze: a1 is Immutable object
	487	• a2 = [1, Object.ne w, 3].free ze: a2 is not immuta ble
	488	•We only n eed to sen d referenc es
	489	• very lig htweight, like threa d-programm ing
	490	•Numeric o bjects, sy mbols, tru e, false, nil are
	491	immutable (from Rub y 2.0, 2.1 , 2.2)
	492	Sharing im mutable ob jects
	493	We can sha re referen ce to immu table obje cts
	494	Guild1 Gui ld2
	495	o2
	496	o3
	497	o1
	498	channel
	499	channel.tr ansfer(o1) o1 = chan nel.receiv e
	500	O2:Data O3 :Data
	501	Ref to
	502	o1
	503	If o1 is i mmutable, any Guild can read o 1
	504	read
	505	Ref to
	506	o1
	507	read
	508	Use-case 1 : master – worker ty pe
	509	def fib(n) ... end
	510	g_fib = Gu ild.new(sc ript: %q{
	511	ch = Guild .default_c hannel
	512	while n, r eturn_ch = ch.receiv e
	513	return_ch. transfer f ib(n)
	514	end
	515	})
	516	ch = Guild ::Channel. new
	517	g_fib.tran sfer([3, c h])
	518	p ch.recei ve
	519	Main
	520	Guild
	521	Fibonacci
	522	Guild
	523	ch
	524	return_ch
	525	n, return_ ch
	526	Answer of fib(n)
	527	NOTE: Maki ng other F ibonacci g uilds,
	528	you can co mpute fib( n) in para llel
	529	Use-case 2 : pipeline
	530	result_ch = Guild::C hannel.new
	531	g_pipe3 = Guild.new( script: %q {
	532	while obj = Guild.de fault_chan nel.receiv e
	533	obj = modi fy_obj3(ob j)
	534	Guild.argv [0].transf er_members hip(obj)
	535	end
	536	}, argv: [ result_ch] )
	537	g_pipe2 = Guild.new( script: %q {
	538	while obj = Guild.de fault_chan nel.receiv e
	539	obj = modi fy_obj2(ob j)
	540	Guild.argv [0].transf er_members hip(obj)
	541	end
	542	}, argv: [ g_pipe3])
	543	g_pipe1 = Guild.new( script: %q {
	544	while obj = Guild.de fault_chan nel.receiv e
	545	obj = modi fy_obj1(ob j)
	546	Guild.argv [0].transf er_members hip(obj)
	547	end
	548	}, argv: [ g_pipe2])
	549	obj = Some Class.new
	550	g_pipe1.tr ansfer_mem bership(ob j)
	551	obj = resu lt_ch.rece ive
	552	Main
	553	Guild
	554	Pipe 1
	555	Guild
	556	obj
	557	Obj’
	558	Move
	559	and modify
	560	Pipe 2
	561	Guild
	562	Obj’’
	563	Move
	564	and modify
	565	Pipe 3
	566	Guild
	567	Obj’’’
	568	Obj’’’
	569	Move
	570	and modify
	571	Move
	572	Use-case:
	573	Bank examp le
	574	Bank
	575	Guild
	576	g_bank = G uild.new(s cript: %q{
	577	while acco unt_from, account_to , amount,
	578	ch = Guild .default_c hannel.rec eive
	579	if (Bank[a ccount_fro m].balance < amount)
	580	ch.transfe r :NOPE
	581	else
	582	Bank[accou nt_to].bal ance += am ount
	583	Bank[accou nt_from].b alance -= amount
	584	ch.transfe r :YEP
	585	end
	586	end
	587	})
	588	…
	589	Other
	590	guilds
	591	Other
	592	guilds
	593	requests
	594	Only bank guild main tains bank data
	595	Use-case:
	596	Introduce special da ta structu re
	597	• Ideas of special d ata
	598	structure to share
	599	mutable ob jects
	600	• Use exte rnal RDB
	601	• In proce ss/externa l
	602	Key/value store
	603	• Software transacti onal
	604	memory
	605	• …
	606	??
	607	Other
	608	guilds
	609	Other
	610	guilds
	611	Summary of use cases
	612	• Making m ultiple wo rkers and compute in parallel
	613	• Requests and respo nses are c ommunicate via chann els
	614	• You can send it wi th copy or move
	615	• Maybe we b applicat ion can em ploy this model
	616	• Making P ipeline st ructures a nd compute in parall el
	617	• Each tas k has own Guild
	618	• Receive target obj ect, modif y it and s end it nex t pipeline
	619	• You will send it w ith move ( transfer m embership)
	620	• It will help appli cations li ke applyin g several filters fo r input da ta
	621	• Own resp onsibility by one Gu ild
	622	• All acce sses are m anaged by one respon sible Guil d
	623	• If you w ant to sha re mutable objects, we need sp ecial data structure s
	624	• External RDBs or k ey/value s tores are also good idea for t his purpos e
	625	Communicat ion strate gy
	626	[Upper is better]
	627	•Passing i mmutable o bjects
	628	•Copy muta ble object s
	629	• If you h ave perfor mance prob lem, move
	630	(transfer membership ) mutable objects
	631	• If you h ave perfor mance prob lem too, u se
	632	special da ta structu re to shar e mutable objects
	633	Compare be tween
	634	Thread mod el and Gui ld model
	635	•On thread s, it is d ifficult t o find out which obj ects
	636	are shared mutable o bjects
	637	•On Guilds , there ar e no share d mutable objects
	638	• If there are speci al data st ructure to share mut able
	639	objects, w e only nee d to check around th is code
	640	→ Encourag e “Safe” a nd “Easy” programmin g
	641	Compare be tween
	642	Thread mod el and Gui ld model
	643	•On thread s, inter t hreads com munication is very f ast.
	644	•On guilds , inter gu ilds commu nication i ntroduce
	645	overhead
	646	• “Move” ( transfer m embership) technique can reduc e
	647	this kind of overhea ds
	648	Trade-off: Performan ce v.s. Sa fety/Easil y
	649	Which do y ou want to choose?
	650	Digression : The name of “Guild ”
	651	•“Guild” i s good met aphor for “object’s
	652	membership ”
	653	•Check dup lication
	654	• First le tter is no t same as other simi lar abstra ctions
	655	• For vari able names
	656	• P is for Processes , T is for Threads, F is for F ibers
	657	• There ar e no dupli cating top -level cla sses and
	658	modules in all of ru bygems
	659	Implementa tion of “G uild”
	660	•How to im plement in ter Guilds communica tion
	661	•How to is olate proc ess global data
	662	How to imp lement int er Guilds
	663	communicat ion
	664	•Copy
	665	•Move (tra nsfer memb ership)
	666	Copy using Channel
	667	Guild1 Gui ld2
	668	o2
	669	o3
	670	o1
	671	channel
	672	o2
	673	o3
	674	o1
	675	COPY
	676	channel.tr ansfer(o1) o1 = chan nel.receiv e
	677	O2:Data
	678	O3:Data
	679	O2:Data
	680	O3:Data
	681	Copy using Channel
	682	Implementa tion
	683	Guild1 Gui ld2
	684	o2
	685	o3
	686	o1
	687	channel
	688	o2
	689	o3
	690	o1
	691	(1) Make
	692	deep copy
	693	channel.tr ansfer(o1) o1 = chan nel.receiv e
	694	O2:Data
	695	O3:Data
	696	O2:Data
	697	O3:Data
	698	Copy using Channel
	699	Implementa tion
	700	Guild1 Gui ld2
	701	o2
	702	o3
	703	o1
	704	channel
	705	o2
	706	o3
	707	o1
	708	(2) Move/J oin
	709	channel.tr ansfer(o1) o1 = chan nel.receiv e
	710	O2:Data
	711	O3:Data
	712	O2:Data
	713	O3:Data
	714	We can use CoW
	715	technique for data
	716	Move using Channel
	717	Guild1 Gui ld2
	718	o2
	719	o3
	720	o1
	721	channel
	722	MOVE
	723	channel.tr ansfer_mem bership(o1 ) o1 = cha nnel.recei ve
	724	O2:Data
	725	O3:Data
	726	Move using Channel
	727	Guild1 Gui ld2
	728	channel
	729	o2
	730	o3
	731	o1
	732	MOVE
	733	channel.tr ansfer_mem bership(o1 ) o1 = cha nnel.recei ve
	734	O2:Data
	735	O3:Data
	736	-
	737	-
	738	-
	739	From Guild 1 perspect ive,
	740	transferre d objects are invali dated
	741	Move using Channel
	742	Implementa tion
	743	Guild1 Gui ld2
	744	o2
	745	o3
	746	o1
	747	channel
	748	o2
	749	o3
	750	o1
	751	(1) Make
	752	deep copy
	753	channel.tr ansfer_mem bership(o1 ) o1 = cha nnel.recei ve
	754	O2:Data O3 :Data
	755	-
	756	-
	757	-
	758	(2) Invali date origi nals
	759	Move using Channel
	760	Implementa tion
	761	Guild1 Gui ld2
	762	o2
	763	o3
	764	o1
	765	channel
	766	o2
	767	o3
	768	o1
	769	(3) Move/J oin
	770	channel.tr ansfer_mem bership(o1 ) o1 = cha nnel.recei ve
	771	O2:Data O3 :Data
	772	-
	773	-
	774	-
	775	(2) Invali date origi nals
	776	Ruby globa l data
	777	• Global v ariables ( $foo)
	778	• Change t hem to Gui ld local v ariables
	779	• Class an d module o bjects
	780	• Share be tween guil ds
	781	• Class va riables
	782	• Change t hem to gui ld local. So that it is guild/ class loca l variable s
	783	• Constant s
	784	• Share be tween guil ds
	785	• However if assigne d object i s not a im mutable ob ject, this constant is accesse d only by setting gu ilds. If o ther
	786	guilds try to access it, them cause erro r.
	787	• Instance variables of class and module objects
	788	• Difficul t. There a re several approache s.
	789	• Proc/Bin ding objec ts
	790	• Make it copy-able with env o bjects or env indepe ndent obje cts
	791	• ObjectSp ace.each_o bject
	792	• OMG
	793	Interprete r process global dat a
	794	• GC/Heap
	795	• Share it . Do stop the world parallel m arking- an d lazy con current sw eeping.
	796	• Synchron ize only a t page acq uire timin g. No any synchroniz ation at c reation ti me.
	797	• Inline m ethod cach e
	798	• To fill new entry, create an inline ca che object and updat e atomical ly.
	799	• Tables ( such as me thod table s and cons tant table s)
	800	• Introduc e mutual e xclusions.
	801	• Current working di rectory (c wd)
	802	• Each gui ld should have own c wd (using openat and so on).
	803	• Signal
	804	• Design n ew signal delivery p rotocol an d mechanis m
	805	• C level global var iables
	806	• Avoid th em.
	807	• Main gui ld can use C extensi ons depend s on them
	808	• Current thread
	809	• Use TLS (temporary ), but we will chang e all of C APIs to r eceive con text data as first p arameter i n the futu re.
	810	Performanc e evaluati on
	811	•On 2 core virtual m achine
	812	• Linux on VirtualBo x on Windo ws 7
	813	•Now, we c an’t run R uby progra m on other than
	814	main guild , so other guilds ar e implemen ted by C
	815	code
	816	Performanc e evaluati on
	817	Simple num eric task in paralle l
	818	Main
	819	Guild
	820	Fibonacci
	821	GuildFibon acci
	822	GuildFibon acci
	823	GuildFibon acci
	824	Guild
	825	Total 50 r equests to compute f ib(40)
	826	Send 40 (i nteger) in each requ est
	827	Execution
	828	time (sec)
	829	Single-Gui ld 19.45
	830	Multi-Guil d 10.45
	831	Performanc e evaluati on
	832	Copy/Move
	833	Main
	834	Guild
	835	sum
	836	sum
	837	sum
	838	sum
	839	Guild
	840	Total 100 requests t o compute sum of arr ay
	841	Send (1..1 0_000_000) .to_a in e ach reques t
	842	Execution
	843	time (sec)
	844	Single-Gui ld 1.00
	845	Multi/ref 0.64
	846	Multi/move 4.29
	847	Multi/copy 5.16
	848	Too slow!!
	849	Because “m ove” need to
	850	check all of element s
	851	Performanc e evaluati on
	852	Copy/Move
	853	Main
	854	Guild
	855	sum
	856	sum
	857	sum
	858	sum
	859	Guild
	860	Execution
	861	time (sec)
	862	Single-Gui ld 1.00
	863	Multi/ref 0.64
	864	Multi/move 0.64
	865	If we know this arra y only has immutable objects,
	866	we don’t n eed to che ck all ele ments => s pecial dat a structur e
	867	Check our goal for R uby 3
	868	• We need to keep co mpatibilit y with Rub y 2.
	869	• OK: Only in main g uild, it i s compatib le.
	870	• We can m ake parall el program .
	871	• OK: Guil ds can run in parall el.
	872	• We shoul dn’t consi der about locks any more.
	873	• OK: Only using cop y and move , we don’t need to c are locks.
	874	• We can s hare objec ts with co py, but co py operati on should be fast.
	875	• OK: Move (transfer membershi p) idea ca n reduce o verhead.
	876	• We shoul d share ob jects if w e can.
	877	• OK: We c an share i mmutable o bjects fas t and easi ly.
	878	• We can p rovide spe cial objec ts to shar e mutable objects li ke Clojure
	879	if we real ly need sp eed.
	880	• OK: Yes, we can pr ovide.
	881	Summary
	882	• Introduc e “why thr eads are v ery diffic ult”
	883	•Propose n ew concurr ency abstr action “Gu ild” for
	884	Ruby 3
	885	•Not imple mented eve rything ye t, but I s how key
	886	ideas and preliminar y evaluati on
	887	Thank you for your a ttention
	888	Koichi Sas ada
	889	<ko1@herok u.com>
	890
	891	Approach c omparison
	892	Process/MV M Place (R acket) Gui ld
	893	(copy/move )
	894	Thread
	895	Heap Separ ate Separa te Share S hare
	896	Communicat ion
	897	Mutable ob jects
	898	Copy Copy Copy/Move Share
	899	Communicat ion
	900	Frozen obj ect
	901	Copy Share (maybe) S hare Share
	902	Lock Don’t need Don’ t need (mo stly) Don’ t need Req uired
	903	ISeq Copy Share Shar e Share
	904	Class/Modu le Copy Co py (fork) Share Shar e