Closed SteveDraper closed 9 years ago
If the queue can be accessed by more than one thread then we have bigger issues because it isn't thread-safe. Isn't it always that tree thread which adds node refs to the completion queue?
Ah yes you're right it is, which (on reflection) makes it a bit trickier, because the reason for having the queue is so that we don't wind up processing the completion of ancestors under the feet of the current expansion! That means we can't just drain it on filling up. Probably means we have to extend (and copy) the buffer when this happens.
On Wed, Jun 17, 2015 at 10:24 AM, Andrew Rose notifications@github.com wrote:
If the queue can be accessed by more than one thread then we have bigger issues because it isn't thread-safe. Isn't it always that tree thread which adds node refs to the completion queue?
— Reply to this email directly or view it on GitHub https://github.com/SanchoGGP/ggp-base/issues/295#issuecomment-112844698.
Fixed - under #270.
In a game of English Draughts (110 moves in and very close to the end of an inevitable draw, when likely all paths are completing as the end becomes apparent):
2015-06-17 10:13:43,062 INFO TreeNode Move noop scores 50.05 (selectionScore score 47.51, selection count 326829, ref 335009146156, RAVE[0, 43.89]) 2015-06-17 10:13:43,062 DEBUG TreeNode Response ( move g 8 h 7 ) scores [50.04, 49.96], visits 66980, ref : 231931116542, RAVE[128013, 49.94] 2015-06-17 10:13:43,062 DEBUG TreeNode Response ( move g 8 f 7 ) scores [50.09, 49.91], visits 35242, ref : 283468199067, RAVE[151060, 49.94] 2015-06-17 10:13:43,062 DEBUG TreeNode Response ( move e 4 f 3 ) scores [56.85, 43.15], visits 642, ref : 249108564332, RAVE[66162, 49.96] 2015-06-17 10:13:43,062 DEBUG TreeNode Response ( move e 4 f 5 ) scores [50.06, 49.94], visits 44531, ref : 231929414149, RAVE[62327, 49.94] 2015-06-17 10:13:43,062 DEBUG TreeNode Response ( move e 4 d 5 ) scores [50.03, 49.97], visits 68108, ref : 300649230822, RAVE[63374, 49.95] 2015-06-17 10:13:43,062 DEBUG TreeNode Response ( move e 4 d 3 ) scores [50.11, 49.89], visits 28322, ref : 352187694370, RAVE[62636, 49.94] 2015-06-17 10:13:43,062 DEBUG TreeNode Response ( move c 4 b 3 ) scores [67.38, 32.62], visits 47, ref : 249108611628, RAVE[26806, 49.88] 2015-06-17 10:13:43,062 DEBUG TreeNode Response ( move c 4 d 3 ) scores [50.01, 49.99], visits 83173, ref : 292058507775, RAVE[59289, 49.96] 2015-06-17 10:13:43,062 DEBUG TreeNode Response ( move c 4 b 5 ) scores [55.33, 44.67], visits 2214, ref : 266290513502, RAVE[41172, 49.94] 2015-06-17 10:13:43,062 DEBUG TreeNode Response ( move c 4 d 5 ) scores [50.11, 49.89], visits 26049, ref : 352188855828, RAVE[43610, 49.94] 2015-06-17 10:13:43,062 INFO TreeNode Most likely path: noop, ( move c 4 d 3 ) | ( move g 2 f 1 ), ( move d 3 c 4 ) | ( move a 4 b 5 ), ( move f 1 g 2 ), ( move g 8 f 7 ) | ( move a 2 b 3 ), ( move a 6 b 5 ) | ( move b 3 a 2 ), ( move f 7 g 6 ) | ( move a 2 b 1 ), ( move b 5 a 4 ) | ( move b 1 a 2 ), ( move a 4 b 5 ) | ( move a 2 b 1 ), ( move b 5 a 6 ) | ( move b 1 c 2 ), ( move e 4 f 3 ) | 2015-06-17 10:13:43,062 INFO MCTSTree Num nodes in use: 2970000 2015-06-17 10:13:43,062 INFO MCTSTree Num true rollouts added: 215951 2015-06-17 10:13:43,062 INFO MCTSTree Num terminal nodes revisited: 36935 2015-06-17 10:13:43,062 INFO MCTSTree Num incomplete nodes: 0 2015-06-17 10:13:43,062 INFO MCTSTree Num completely explored branches: 352902 2015-06-17 10:13:43,062 INFO MCTSTree Current observed rollout score range: [0, 100] 2015-06-17 10:13:43,062 DEBUG GameSearcher Factor best move: noop 2015-06-17 10:13:43,062 INFO Sancho Playing move: noop 2015-06-17 10:13:43,062 DEBUG Sancho Move took: 42250 2015-06-17 10:13:48,210 DEBUG GameSearcher Dynamic sample size 2015-06-17 10:13:48,210 DEBUG GameSearcher Useful work last time: 5% 2015-06-17 10:13:48,210 DEBUG GameSearcher Calculated sample size: 5 2015-06-17 10:13:48,210 DEBUG GameSearcher Suppress update: true 2015-06-17 10:13:48,210 DEBUG GameSearcher Now using sample size: 1 (forced by use of RAVE) 2015-06-17 10:13:48,210 DEBUG GameSearcher Useful work total: 23% 2015-06-17 10:13:48,997 WARN NodeRefQueue Not inserting node ref 420909113802 because the queue is full 2015-06-17 10:13:48,997 WARN NodeRefQueue Not inserting node ref 249110408750 because the queue is full 2015-06-17 10:13:48,997 WARN NodeRefQueue Not inserting node ref 274880794185 because the queue is full 2015-06-17 10:13:48,997 WARN NodeRefQueue Not inserting node ref 283467938386 because the queue is full 2015-06-17 10:13:48,997 WARN NodeRefQueue Not inserting node ref 395137121185 because the queue is full 2015-06-17 10:13:48,997 WARN NodeRefQueue Not inserting node ref 377957814922 because the queue is full 2015-06-17 10:13:48,997 WARN NodeRefQueue Not inserting node ref 266290334525 because the queue is full 2015-06-17 10:13:48,998 WARN NodeRefQueue Not inserting node ref 266288562523 because the queue is full 2015-06-17 10:13:48,998 WARN NodeRefQueue Not inserting node ref 292059027080 because the queue is full 2015-06-17 10:13:48,998 WARN NodeRefQueue Not inserting node ref 300648845896 because the queue is full 2015-06-17 10:13:52,098 DEBUG RequestFactory GGP-Match-Step: 110 2015-06-17 10:13:52,098 DEBUG RequestFactory GGP-Match-Host: Tiltyard 2015-06-17 10:13:52,098 DEBUG RequestFactory GGP-Match-Players: 29756f66ce52a046aad9b3bccf89632a1df45d43, 13b04635bc91d3d1d57b89e9c2deaca5b62c56ac 2015-06-17 10:13:52,098 DEBUG RequestFactory GGP-Match-ID: tiltyard.englishDraughtsv0.1434548592463
I don't think we can just throw these away, but can't we: a) (if the queuing thread is NOT the search thread) sleep until not full (spin wait); or b) (if the queuing thread IS the search thread) drain the queue first