And you are here why?

“ Locking is easy — just use a mutex!”         --#CowboyDeveloper One of the surest “tells” of a  #CowboyDeveloper  is their behavior around a shared resources. Odds are they’ll slap a mutex around it (or around  something ), and keep going. Oh, if you really poke at them, they might be able to ( intelligently? maybe not ) say  something  about  mutexes vs semaphores vs spin-locks vs … , but, seriously, in their mind, “I t’s all so simple! You just lock/unlock it! Like, with mutexes! ” The above, mind you, as contrasted with the  excellent work by Willy Tarreau (most definitely  not  a #CowboyDeveloper) on  Progressive Locks . “What are they?” you ask? Well, if you’ve got a resource (tree, list, whatever) where you’re usually reading the resource, but, sometimes, you want to write  only  if your Read succeeded. In short, you want to be able to “upgrade” from a Read to a Write. S...

Redis is fast — wicked fast.   Blazing   fast even. Most of this is because, for the longest time, its core event-loop was just a (very!) lightweight wrapper around epoll/kqueue/whatever, with almost all the focus placed on nom-blocking behavior. Herewith a nifty walkthrough of the internals —  https://goo.gl/gUzCN  — in the context of building concurrent systems focused on sheer performance. (°) BTW, there is actually some threading in there now. Freeing memory and fsync/persistence are now handled by a — strictly controlled! — set of redis specific background threads. There are also “long running user ops” (warning — here be Dragons!) that spin up their own threads.   #TIL (°) This nugget —  createClient’s… sets the socket to non-blocking mode (a key ingredient in an asynchronous event loop)  — brought back a lot of unpleasant memories. It may have been the single most common issue I’ve seen in networking code. Or made, for that matter

The two languages I am most comfortable with nowadays are erlang/OTP and perl - which, strangely enough, makes me quite remarkably non -conflicted.  The key, I guess, is that they are so different, with the core use-cases being so fundamentally distinctive, that there really isn't that much of a context switch for me to move from one to the other.  And, of course, given their radically different natures, I rarely (never?) ever use one when I should have used the other. Erlang/OTP, of course, is your classic massively concurrent fault-tolerant distributed infrastructure language, which pretty much gives you all the aforesaid buzz-word properties by default.  You have to work, and quite hard at that, at making your system behave badly.   I could go on and on about why its the greatest thing ever, but others have done it far better (e.g. John Bender here or Alex here ), but I will say that once you have tested the beauty of the built-in concurrency, sup...

I just finished a fascinating paper  " Challenging the Computational Metaphor " by Lynn Andrea Stein .  The main focus is in trying to get us to move from a world of Computation as Calculation , to one of Computation as Interaction . Quick definition time - Computation as Calculation :  Breaking a problem into a sequence of steps that need to be be logical, and sequentially calculated on a set of inputs, to get to a result. Computation as Interaction :  Representing an environment as a sequence of interacting entities, with the emergent property of the interaction as the result Stein postulates that the Calculation approach is embedded into the very fabric of every thing we do, and everything we teach.  It has served us extremely well up till recently, with the enforced abstraction being vital to our ability to construct functioning systems.  It has also bled into the rest of the world, with a continued focus on everybody's part to systematize an...

Edward A. Lee (of Ptolemy fame) is the Robert S. Pepper Distinguished Professor at U.C. Berkeley, and knows a thing or two about designing and building concurrent systems.  He also has a hate-hate relationship with Threads, as evidenced by my perusal of The Problem with Threads (Jan 2006).  For example Threads [...] are wildly non-deterministic  non-trivial multi-threaded programs are incomprehensible to humans we […] require that programmers of multi-threaded systems be insane. Were they sane, they could not understand their programs If we expect concurrent programming to be mainstream, and if we demand reliability and predictability from programs, then we must discard threads as a programming model  And there is more, oh so much more.  Just read the whole thing - its wickedly entertaining, and makes its points with no small amount of wit and humor.  Herewith a quick look at the points made in the paper. Note : All of the below applies to T...