WIP: Concurrent hydro interactions via particle-carried spin locks
Here is a first-draft implementation of the atomic tasks for the hydro scheme.
To simplify things, each particle carries a lock and we try to acquire it in the tasks when we identify that a given particle will be updated. This reduces the amount of unnecessary locking of an entire array of particles when for instance writing back from a cache.
Thoughts welcome on this! It does yield the correct answer and is a bit faster. Only a bit as the hydro was already pretty good. @pdraper any thoughts from you as well on this?
Note for self: Need to deal with MPI. Probably by re-initialising the lock upon receiving the data.
Merge request reports
Activity
added 1 commit
- 3fbe5f90 - Add the particle-carried lock to the Gadget hydro scheme
added 7 commits
-
a7a42229...e8b4adc6 - 6 commits from branch
master - 6a905a9e - Merge branch 'master' into 'locked_hydro'
-
a7a42229...e8b4adc6 - 6 commits from branch
@pdraper I have looked at implementing the checks you suggested (only in the SPHENIX hydro scheme for now). This does work but the check is only partially valid. It can test whether the lock has been acquired but can't tell you whether it was acquired by the calling thread.
src/part_lock.h 0 → 10064446 * @brief Initialise the lock of a particle. 47 * 48 * @param p Pointer to the particle (part, spart, gpart, bpart,...) 49 */ 50 #define swift_particle_lock_init(p) ((p)->lock = 0) 51 52 /** 53 * @brief Lock a particle for access within this thread. 54 * 55 * The thread will spin until the lock can be aquired. 56 * 57 * @param p Pointer to the particle (part, spart, gpart, bpart,...) 58 */ 59 #define swift_particle_lock_lock(p) \ 60 ({ \ 61 while (atomic_cas(&((p)->lock), 0, 1) != 0) { \ changed this line in version 6 of the diff
