freenode/#clim - IRC Chatlog
Search
8:08:41
beach
loke: I think I pretty much finished the design of the synchronization protocol between the global garbage collector and the per-thread nursery collectors. When you have time (obviously not today), I would appreciate if you would take a look.
9:43:47
beach
loke: I mentioned condition variables because I never quite understood how they work, and I suspect my combination of CAS and semaphores is exactly what condition variables do.
13:33:32
loke
It might be that it ended up being a client-side networking issue, resutiing is what looked _exactly like one of the services on the server had hung
13:34:00
loke
When you have an application on the oder of 100 million lines of code, debugging that crap tends to be... annoying.
13:34:40
loke
Anyway, I had some time to hack on climaxima while the server applications was restating :-)
13:36:17
makomo
beach: if there's one thing i would like to see, it would be a nice little concurrency dictionary where all of the terminology is defined once and for all
13:37:18
loke
beach: I know there is some copy&paste code in there, I have randomly been able to paste in some input fields (the text edit gadget, I think). However, I use DREI for everything, so I need to implement copy&paste for DREI
13:37:30
makomo
well, i can't claim that it isn't, but yet whenever i read any article about concurrency i always see a slightly different definition
13:39:30
loke
you can implement everything (including sempahores) if all you have are mutexes and condition variables.
13:40:00
loke
makomo: Fair enough. I never really think of the mutex as having "state" as such, but you are right.
13:41:23
loke
makomo: you can inquire a semaphore and get ON or OFF back. A mutex can't (necessarily) be inquired
13:43:47
loke
ACTION usually ends up building my tools from scratch using just condvars and mutextes.
13:44:18
loke
Probably because I started out using pthreads back in the 90's. Didn' thave any more complex structures to work with, so I had to do it all myself. I sitll feel more comfortable doing so to this day
13:44:30
makomo
another thing: concurrency, parallelism, multitasking, multithreading, multiprocessing, synchrony, asynchrony
13:45:09
makomo
most of these are ok i would say, but it's just that people abuse them to mean something else
13:45:43
loke
makomo: I think it's mostly because a lot of people thy to build concurrent application without understanding the conceps.
13:46:00
beach
From what I can tell, a lock/mutex is held by a particular process, and only that process can release it. A semaphore on the other hand does not have that kind of restriction. Anyone can do wait or signal.
13:46:02
loke
That's when you end up with epople writing Java and slapping “synchronized” on every bethodm becayse threading.
13:46:31
makomo
beach: yep, i think that's what wikipedia says as well. but that is also an implementation detail for me
13:47:09
makomo
i guess it might make sense to have some common lanugage for "a lock only the process that locked it can unlock", but lock/mutex/semaphore are all too closely linguistically related for me
13:52:28
makomo
then there are also things like recursive mutexes, but here the "recursive" part of the name says exactly how the object is different
13:53:27
makomo
that's much better than lock vs. mutex vs. binary semaphore (all of these are too vague -- they describe the same concept but don't hint at any implementation details (which is where the difference ends up being))