01:48 ilbot3 joined 04:35 vendethiel joined 06:12 rurban_ joined 06:53 Ven joined
jnthn I wasn't aware there was more than one (common) definition of reentrancy for mutexen either :) 06:54
But anyway, here goes: if a thread already holding a lock acquires it a second time, it's effectively a no-op, as is that nested lock release 06:56
Note that this means it's a dynamically scoped property
07:06 Ven joined 07:10 FROGGS joined 07:14 harrow joined 07:22 zakharyas joined 07:40 JimmyZ joined 07:55 vendethiel joined, brrt joined
brrt \o 07:55
FROGGS o/
brrt hmm 07:56
it just occured to me that i can use graphiz to represent the code trees for my blog
that might make some things much more clear 07:57
*graphviz 08:01
FROGGS aye 08:08
jnthn I had to teach so didn't get to finish on the lock thing. :) I suspect that I'll have Lock.protect(...) install a $*AWAITER that dies. 08:19
To try and catch most cases where people await while holding a lock 08:20
Because it's basically always wrong.
(for one 'cus your code can migrate between OS threads at the point of an "await") 08:21
(and locks are tied to OS threads, so you'd end up trying to release it on the wrong thread)
lizmat jnthn: on that note, would you like me to merge your new S17 proposal into the spec, or do you want to do that yourself? 08:22
jnthn lizmat: I don't think it has to be me that does it, though we may want to defer it until I've had chance to work on implementation. 08:24
lizmat ok, deferring is fine with me :-)
jnthn Then I can tweak the gist with any findings while I implement :) 08:25
timotimo a better idea to complain on await than on start
i like that
jnthn Complaining on start doesn't make a lot of sesne to me
It's not really a problem to schedule some work while holding a lock.
It's blocking while you do it 08:26
timotimo yeah
brrt wait, what, your await can transfer your code to another thread?
timotimo i just now see that the suggestion last night was to set the $*SCHEDULER to CurrentThreadScheduler
rather than complain or something
jnthn brrt: Yes.
timotimo brrt: it's supposed to take a continuation that can later be invoked again
brrt i.e. my $x = start { foo; }; await $x;
jnthn brrt: I described that in the gist I wrote ;) 08:27
brrt can start on another thread? doesn't just lock and wait?
which gist was that? if you didn't publish so much interesting stuff, i might be able to renember :-P
oh
timotimo gist.github.com/jnthn/a56fd4a22e7c43080078
jnthn bah, timotimo++ can find my gists faster than I can :P
brrt anyway, yeah, awaiting in a lock is a pretty bad idea
jnthn In C# they have syntax for lock (for one very particular type of lock...grmbl) and the compiler forbids an await inside of a lock block. We can't do that, but we can do the more dynamic analysis. 08:30
brrt hmm 08:33
java is worse (of course)
java synchronized blocks are nearly useless
timotimo is that so? are they anything more than a little monitor? 08:34
brrt hmm yeah, they are reentrant? and they have very funky wait() and notify() semantics 08:38
my point is actually, monitor semantics are not all that useful in trying to make good code
timotimo it's a very rough primitive that gives you broad exclusion 08:39
you can get better code by using finer locks or a different kind of primitive altogether, i suppose
brrt it's not a good primitive (and neither are locks) 08:48
channels / queues, supplies, promises etc are much better
jnthn Having locks and cond vars to hand is really really useful as building blocks 09:03
But they're not what you want to work with directly most of the time
brrt concurrency is weird like that 09:25
nobody thinks anything of using addition, subtraction, function calls as building blocks for larger applications
but low-level concurrency primitves don't scale at all
high-level 'pseudoprimitives' like queues/channels/etc are not a problem 09:26
10:02 brrt` joined 10:15 vendethiel joined
jnthn To be fair, the higher level concurrency abstractiosn are a more recent arrival in mainstream languages. 11:02
11:05 zakharyas joined 11:13 rurban_ joined 12:21 vendethiel joined 12:38 Ven joined 13:30 Ven joined 13:55 nebuchadnezzar joined 14:21 flussence joined 15:03 hoelzro_ii joined 15:20 Ven joined 16:00 Ven joined 16:52 brrt joined 17:04 ggoebel joined 17:22 TimToady joined 18:04 colomon joined 18:20 colomon_ joined 18:52 vendethiel joined 19:03 rurban_ joined 19:04 brrt joined 19:19 vendethiel joined 19:39 brrt joined
brrt blog: brrt-to-the-future.blogspot.nl/2015...ilers.html 20:03
lizmat brrt: do you still take comments about spelling errors ? 20:13
brrt that i do
:-)
lizmat expresion: result = LOCAL[8] + 12 "expression"
brrt ah
fixed that one 20:15
any more?
lizmat not yet :-)
Fortunately, chichken-and-egg "chicken-and-egg" 20:18
brrt aye
20:22 TEttinger joined
lizmat that's it... exciting! 20:22
brrt :-) it's pretty cool stuff, i think 20:23
you know what i find funny
i was halfway through the work until i realised 'hey, i'm creating a DFA'
lizmat no?
hehe
see, I know your CS study would come in handy :-)
jnthn home o/ 20:24
brrt \o/
lizmat jnthn o/
brrt (i'm not actually a CS student... :-))
i'm off for tonight
lizmat good night, brrt! 20:25
brrt good night!
jnthn
.oO( I used to be a CS student, but then I took a bachelor degree )
 20:28
brrt: It seems that in the "naive code", the 12 has gone missing? 21:33
And also r0 isn't used 21:34
brrt++ # nice post, and really nice work 21:37
21:52 timo joined 23:02 raiph joined
raiph This Jan 2015 article might be of interest to at least brrt: Data-reuse Optimizations for Pipelined Tiling with Parametric Tile Sizes # hal.inria.fr/hal-01111393/file/main.pdf 23:09

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!