Mutex Blocks

When I was taking a compilers course, I noticed the grammars for C/C++/Java etc. allow for blocks with no conditional or function signature at the top. I couldn’t think of what this would be used for except to make the grammar easier to describe. Later, while writing code with lots of mutual exclusion, my code was getting hard to read. My friend Logan suggested if most mutexes are small blocks of code, why not use braces to denote them? Here’s what it looks like:

sema_wait(&shared->mutex);
{
  memcpy(result, current_call->result,
              sizeof(RPCResult));
  ret = current_call->retStatus;
  current_call->next = shared->available;
  shared->available = current_call_index;
}
sema_post(&shared->mutex);

Emacs also nicely indents the blocks which really extends the readability.

As Dan has pointed out, even though the braces are being used as a visual indicator to the programmer, the braced sections are still semantically treated as blocks by the compiler; meaning a new scope is created. This is not necessarily a negative, however, because a lot of the time the new scope can make sense (similar to mutexing an entire function) or, at the very least, not hurt. Dealing with the new scope is as simple as dealing with the new scope of a for-loop. If you are writing threaded code, I hope you can deal with semantic blocks.
    None Found
  • That's right you did show me this. I'll change that right now. Thanks man.
  • someone, but yea, Hosking's code did that ALL the time. <acronym title="If I Recall Correctly">IIRC</acronym> when I showed you that you said "Yea, that makes sense, Hosking did that in compilers"
  • Are you the one that showed me this technique? I thought I got it from Hosking's code but I could be wrong. If you really did show me this, I will change the post to reflect that. Talk to me in class.

    Also, it's true that emacs can indent like you've mentioned but I like the braces because it's nice to think of mutual exclusive code as blocks. Good alternative anyway.
  • I'm glad that what I showed you sparked such controversy!

    Also note, if you are just doing it for the purposes of easy-indentation for/in emacs, you can just as easily use whitespace. As you probably know, if you indent the first line of the block, and emacs will just realign the rest of the code to that.
  • Trevor Wernisch
    I solved this problem in like 2 minutes.
  • 1. My point was simply that you're using "a hole" in the grammar, something I don't agree with.

    2. What if they weren't locked directly next to each other, for some reason?

    3. Well, if your blog post had said that, I probably wouldn't have bothered saying anything. We all do shady things in CS projects ;)

    4. I don't mean every line of code should have a block. What I mean is, one instruction to another human might correspond to more than one line of code. So does it seem better to put those lines of code into a block to clarify that it is a single step to a human?

    Anyway, you come off as getting irritated, so I'll just stop commenting here. The misunderstanding to begin with was that I thought you would use this outside of class.
  • semantic meaning of a mutex lock with the visual meaning of commenting.

    I think the goal here is to solve two problems: One functional and one visual. Functionally, the goal of the code is to make a discrete portion of the code mutually exclusive (lock, modify, unlock). The other goal is to see at a glance that was achieved.

    If your means to that end is solely commenting and whitespace then the pressure is on the developer to visually interpret the functional meaning. This is what I called adding structure to a natural language. Who are you catering to when you do that?

    Things really get meta at this point, but here is how I see it...

    There is code with inherent meaning (cf. html). The code is interpreted by both compilers (cf. web browsers) and programmers (cf. web developers). Here is the part I feel strongly about: one should not compromise their own interpretation for the sake of another. That is, don’t make machine-like statements in an area which a human is expected to interpret and a machine is expected to ignore. If your problem is visual interpretation, braces aren’t the answer. Conversely, if the problem is ensuring safe, correct code no amount of comments will do that.

    That said, do I use the braces? I did for a while in a past project but stopped when I realized there wasn’t a problem to solve--neither I nor the compiler had any trouble interpreting the code. This rant was half for myself since semantics is something I feel pretty strongly about.

    fake edit: That code example I provided explored how I could achieve what I felt was lacking not only in documentation (e.g., links) but also the language (e.g., meta code blocks). (Aside: I tend to disagree with the notion of over commenting in general. Humans too can ignore comments.)
  • 1. This technique wouldn't be used in a language with a more advanced grammar for exactly that reason: it has a more advanced grammar.
    2. If 10 mutexes needed to be locked for the same section of code, only one pair of braces would be needed.
    3. I would never use this technique for anything but course projects where arbitrary techniques may be invented to ease the readability of a not-so-well separated assignment.
    4. It is a bad idea to put "steps" of a function in separate blocks, just as it is bad to put comments above every line of code. Suggesting these extremes is absurd.

    I'm not going to answer any more questions like this because you should really be able to answer these on your own. Also, I really hope people will take these ideas and apply them appropriately: to situations that may benefit from and idea like this. If you don't see how it can be beneficial then don't use it.
  • woops, I didn't include the "do" in "do print 'hello' end"
  • Phil's example is also a bad example of commonly seen code; I've never seen code in used in any real projects that comment every line on a new line. The closest I've seen is comments on the same line in assembly. I think it's better to assume sparse/no comments than to assume over-commented code.

    Do embedded mutexes really help you see the order of your locks? What if there are (highly exaggerated) 10 mutexes you have to lock for the atomic code? That's a helluva lot of indention, even with 2-space indention.

    The reason I think your use of lexical scoping is incorrect is this: Look at some of the languages with more advanced grammars, such as Python and Ruby. Python uses whitespace-sensitive lexing, and Ruby uses [legacy] braces or fancier stuff like do/end for for statements. Try randomly indenting in Python and see what happens, or try putting "{ print 'hello' }" or do "print 'hello' end" into irb. It doesn't work!

    Blocks have never been hard to understand, because usually they're associated with another statement. Do you think other programmers could look at your code and figure out why you declared a new scope immediately? This technique may work for you, but I don't think it works well if you're handing off code to someone you may not ever talk to.

    And to restate my question, do you think putting "steps" of a function in separate blocks will make the code more readable?
blog comments powered by Disqus