[jboss-jira] [JBoss JIRA] Commented: (JBRULES-681) Multi-threaded local search solving

[Geoffrey De Smet (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBRULES-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12510805#action_12510805 ] 

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).

> Multi-threaded local search solving
> -----------------------------------
>
>                 Key: JBRULES-681
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-681
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-planner
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Optional
>
> 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 during solving.
> Problems:
> - 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 bestsolutionrecaller.
> - 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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira