[ https://jira.jboss.org/jira/browse/JBRULES-681?page=com.atlassian.jira.pl... ] 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 workQueues. (A) *** 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 not!) *** 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). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBRULES-681?page=com.atlassian.jira.pl... ] Geoffrey De Smet updated JBRULES-681: ------------------------------------- Summary: Multi-threaded local search, tabu search, ... solving on Decider.decideNextStep (was: Multi-threaded local search solving) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-681?page=com.atlassian.jira.plugi... ] Geoffrey De Smet commented on JBRULES-681: ------------------------------------------ The design not to break delta based incremental score calculation: - Every planning entity gets an internal ID as soon as Planner knows about it. Each thread has one solution cloned. The entities and their id are stored in a map per thread. - When a Move is migrated from the step thread to the move thread, each of it's planning entities (which includes any toPlanningValue that is a planning entity) is replaced by the move thread's correct planning entity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira