Loading ...
Sorry, an error occurred while loading the content.
 

The Freecell Solver Multi-threading Scheme

Expand Messages
  • Shlomi Fish
    I wrote a document about making sure it is possible to run several hard threads in parallel. Your commentary is welcome. Regards, Shlomi Fish Elements in the
    Message 1 of 1 , Jul 22, 2002
      I wrote a document about making sure it is possible to run several hard
      threads in parallel.

      Your commentary is welcome.

      Regards,

      Shlomi Fish

      Elements in the instance struct:

      * The States Collection (however implemented)
      - Protect fcs_caas_check_and_insert() in caas with a mutex.

      + num_states_in_collection;

      - Protect access with a mutex.

      * Individual States
      - Protect parent/depth/num_active_children assignment with a mutex
      - All other fields are not critical.

      * num_times
      - Protect with a mutex.

      * The Stacks Collection
      - Protect cache_stacks with its own mutex

      * num_hard_threads_finished
      - Protect with a mutex


      Do not need to be synced:

      solution_moves - created after the solution was found
      max_depth - a constant and deprecated
      max_num_times - a constant
      debug_iter_output - a constant
      debug_iter_output_context - a constant
      debug_iter_output_func - the user should make sure it syncs.
      freecells_num, stacks_num, decks_num - constants
      sequences_are_built_by, unlimited_sequence_move - constants
      empty_stacks_fill - constants
      optimize_solution_path - constant;
      state_copy_ptr - constant;
      final_state - If two threads write to it at once they will write the
      same state, because the empty state is uniquely identified in the
      states collection.
      max_num_states_in_collection - a constant.
      num_hard_threads - a constant
      hard_threads - a constant
      next_soft_thread_id - a constant.
      ht_idx - not relevant for multi-threaded apps.
      instance_tests_order - a constant
      optimization_thread - used only a posteriori to the main scan.
      calc_real_depth - constant
      scans_synergy - a constant
      to_reparent_states - a constant

      opt_tests_order - used only a posteriori to the main scan.




      ----------------------------------------------------------------------
      Shlomi Fish shlomif@...
      Home Page: http://t2.technion.ac.il/~shlomif/
      Home E-mail: shlomif@...

      He who re-invents the wheel, understands much better how a wheel works.
    Your message has been successfully submitted and would be delivered to recipients shortly.