freenode/#clasp - IRC Chatlog
Search
13:19:26
drmeister
I got a bit better at dtrace - I can now catch when locks are attempted to be acquired and when they are acquired - hopefully now I can quantitate lock contention.
14:03:16
drmeister
I can recover the name of each mutex (they are getting unique names now) and when I ask for the lock and when I get the lock
15:50:17
drmeister
I say appears because all thread safe hash tables have mutexes and they all have the same name at the moment - I'm giving select ones (system hash tables) unique names now.
15:54:22
drmeister
Yeah - there is a hash-table for the classes and that hash-table has upgradable read/write lock. Every find-class involves a read lock and every (setf find-class) or rehash involves a write lock.
16:01:59
drmeister
kpoeck_: I fixed some of the problems with hash tables in MPS with multi-threading. I need to revisit this soon.
17:43:43
Bike
i've never implemented locks before, but as i understand, acquiring one should basically just be an atomic "lock.pid = mypid"
17:48:06
drmeister
Hmm, it looks like my SharedMutex is ok but the UpgradableSharedMutex does not work in a shared read mode.
17:50:39
scymtym
ACTION is working on extending the flamegraph tool to help with debugging this kind of situation: https://techfak.de/~jmoringe/tracer-2.png everything red is blocking: GRAB-MUTEX, CONDITION-WAIT, PROCESS-WAIT, SLEEP
17:53:05
scymtym
drmeister: it needs mcclim, but i understand that mostly works now. furthermore, it uses SBCL's encapsulation to trace function calls and returns. if clasp has something equivalent, it should be possible
17:55:18
scymtym
if you just want to trace blocking primitives, those could be instrumented via redefinition. it is mostly tracing arbitrary user functions that needs encapsulation