freenode/#clasp - IRC Chatlog
Search
15:11:38
Shinmera
Path Replication Using Local Graph Rewriting in Intermediate Code, Control-Flow Analysis in the Presence of Nested Functions and Threads, Partial Inlining of Local Functions Using Local Graph Rewriting
15:58:30
frgo
Oh hi. Good ;-) I get an error on the following line: https://github.com/drmeister/clasp/blob/dev/wscript#L550
15:59:20
drmeister
Sorry - I've been wrapped up in this generic function multithreading issue and not getting 'dev' buildable.
16:01:06
drmeister
I'm not certain that 'dev' will build though - I'll push to testing and give it a try.
16:03:54
drmeister
frgo: The multi-threading issue is on both the lisp side and C++ side. It's the most complicated resource that I've tried to make thread safe - I'm having trouble figuring it out.
16:06:02
frgo
You mentioned "race condition" here ... I don't want to hold you up but I'd be interested to understand a tiny bit more - only if it is explainable in a few lines..
16:08:32
drmeister
Each generic function also has an a-list that maps previous invocation signatures to effective method functions.
16:10:03
drmeister
When a call history changes (several ways that can happen) the discriminating function is set to the 'invalidated-dispatcher' function.
16:10:43
drmeister
When a generic function call happens and it jumps to the invalidated-dispatcher function a new discriminating function is compiled from the call history.
16:12:09
drmeister
No generic functions are invoked when the discriminating function is compiled - but I have to put a write-lock on the code that compiles the discriminating function so that multiple threads don't try to compile/install discriminating functions at the same time.
16:12:57
drmeister
Besides that I need to put write locks on other code that updates the generic function call history, specializer profile, method list etc.
16:13:43
drmeister
Somewhere I'm getting a deadlock when something that has the lock calls something that wants a lock.
16:15:21
frgo
For that 1 generic function's dependent objects like call history etc - so for each GF just 1 lock - or do I misinterpret sth?
16:16:30
drmeister
So not one lock for all generic functions or one lock for each generic function resources - just one lock per generic function.
16:18:26
frgo
Ok - I am thinking: That one lock per GF must be enough - no other locks required as everything else is required to be sequential updates / needs to be synchronized to that one lock.
16:18:27
drmeister
I think I just need to struggle through this - I can barely describe the problem.
16:20:16
frgo
Now you need to pass on the lock through code that is allowed to update the resource - the lock has to be a thread-local variable. If the lock passed on and tghe lock being thread-global are the same the resource is allowed to update.
16:21:58
drmeister
src/lisp/kernel/clos/closfastgf.lsp and src/core/funcallableInstance.cc and src/core/funcallableInstance.h
16:23:14
drmeister
Don't trouble yourself too much - I think I just need to think about it harder. Also, I haven't pushed out the latest code - because it doesn't build yet.
18:21:14
drmeister
I can't write lock the entire generic function when there is a dispatch-miss - that deadlocks.
18:21:52
drmeister
It deadlocks because the same generic function is invoked in the course of the dispatch miss.
18:25:07
drmeister
I'm starting to think though that the generic function read/write lock should be to guard against two threads updating anything in the generic function other than the discriminator function.
18:25:33
drmeister
The discriminator function is an atomic object, a single pointer to a block of code.
18:28:01
drmeister
If two threads each evaluate the same generic function and they both lead to a dispatch miss - then I need to protect the call-history from being updated by two threads at the same time - but not the discriminating function.
18:28:33
drmeister
If one thread updates the discriminating function and then the other overwrites it - it's no big deal. There will be another dispatch-miss and that will rebuild the discriminating function again.
0:01:41
drmeister
It's a read/write lock where you can upgrade it from a read lock to a write lock without giving the lock up.
0:02:23
drmeister
There's a lot of reading and then a burst of writing in the dispatch-miss function.
0:08:46
drmeister
Crap - that won't be adequate - if two threads both dispatch-miss at the same time it will still deadlock