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_at_vipe.technion.ac.il
Home Page:
http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif_at_iglu.org.il
He who re-invents the wheel, understands much better how a wheel works.
Received on Mon Jul 22 2002 - 07:48:34 IDT