Geoffrey De Smet commented on JBRULES-681:
It's the homogeneous moves (as Java Currency in practice teaches us) that need to be
spread on multiple threads.
* One step thread (the thread which called solve())
** Starting solution is created on the step thread (later we'll see if we can do
multithreading support there too)
** It has a workingSolution (which is does already)
** multithreading starts from decideNextStep
* N move threads
** Typically N = the number of CPU's (minus 1?)
*** NOT the number of selected moves!
** Each has a work queue of Moves (= 1/N th of the selected moves)
*** The stepThreads creates the Moves and distributes them among the moveThread
*** The moveThreads can steal from the end of each other => work stealing queues
**** probably use Java 6 implementations
**DO NOT BREAK DELTA BASED SCORE CALCULATION!!! (See latest ref manual to understand why
*** Each moveThread has it's own workingSolution in a ThreadLocal
*** A move from the workQueue of which the score and acceptChance needs to be calculated
is done and undone on the moveThread's workingMemory.
*** The stepMove (= winning move) is applied to the stepThread's workingSolution as
well as on every moveThread's working solution
**** So it needs to be cloned?
***** And applied on several solutions (B)
(A) and (B) have problem to which I know no best answer at the moment:
A Move holds a reference to an instance (for example Exam) of the stepThread's
workingSolution (for example Examination).
But when given to a moveThread it should execute on the instance of the moveThread's
workingSolution, which is a different instance(actually a clone of the original Exam, but
a different instance).
Multi-threaded local search solving
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Use Future's to spread all possible moves in each step over a number of threads.
This number of threads is equal to the number of cpu's by default, as no IO is done
- each thread will needs it own WorkingMemory and during a step, each working memory will
need to be updated
- a bunch of classes will need to be thread safe, or at least visibility save, such as
- Barriers will be needed to collect the result of each step
- decks might be a great way to spread out the load
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see: http://www.atlassian.com/software/jira