search

spirit-code / spirit

Atomistic Spin Simulation Framework
http://spirit-code.github.io
MIT License
117 stars 52 forks source link

Core: replace manual mutex locks, if possible #436

Closed GPMueller closed 3 years ago

GPMueller commented 6 years ago

Potentially, some parts of the design won't allow this, but it would be best to use scoped locks instead of manual lock/unlock calls, see also http://kayari.org/cxx/antipatterns.html#locking-mutex

One question is, whether images need to be locked when the chain is manipulated - and if yes, then how?

GPMueller commented 5 years ago

A solution to this might be to change the locking procedures. Instead of locking the parameters etc. which reside within the images and chain, the Method could copy parameters over from the State if a corresponding increment shows that they changed.

This would allow the separation of the write and read accesses, preventing most blocking caused by colliding mutex locking calls.

GPMueller commented 5 years ago

Should take some inspiration from http://blog.vorbrodt.me/?p=409

GPMueller commented 5 years ago

This might be a good library to use for thread-safety: https://github.com/LouisCharlesC/safe It is described quite nicely here: https://www.fluentcpp.com/2019/04/26/how-to-write-safe-and-expressive-multi-threaded-code-in-cpp11/

However, I don't see how to get rid of the issues of lagging GUIs when variables are accessed rapidly during a simulation (see #144).

GPMueller commented 5 years ago

This might be a nice library for a lock queue: https://github.com/max0x7ba/atomic_queue and this might be a good read: http://alinloghin.com/articles/command_buffer.html

GPMueller commented 3 years ago

Closing as PR #558 has been merged.