A Defer Mechanism for C

Re:A Defer Mechanism for C by gpderetta on Monday December 14, 2020 @11:18AM (#25419265)

it is a bit annoying yes. There are some proposals to have a anonymous reusable placeholders like '_', but they haven't gone anywhere yet.

You can do

    lock(mutex), some-lock-protected-expression;

but it is a bit too cute and limited.

On the other hand, being able to name the RAII object is often very useful for example if you need to dismiss them early, which happens often in transactional code (unlocking a mutex before the end of scope is a relatively common occurrence).

Also specifically for mutexes, a nice pattern is to bind object and mutex together to guarantee that the object is always used with the lock:

   sync<my_object> foo;

   {
     auto l = foo.lock(); // starts the critical section

     l->do_something()
     l->do_something_else();
   } // it ends here

   // or if you only need to hold the mutex for a single call:

   foo->do_something(); // critical section lives only for the full expression

[ Parent | on HN ]

Re:A Defer Mechanism for C by dkersten on Monday December 14, 2020 @12:50PM (#25420648)

> On the other hand, being able to name the RAII object is often very useful

I didn't say it wasn't. Being able is perfectly fine, being forced is not. As I mentioned in another comment, the problem isn't the extra typing, the problem is that it requires us, the programmer, to remember to name it even when we don't feel we need and to remember that "foo (bar)" isn't calling the constructor of foo and passing in bar, its calling the default constructor and declaring bar. That's too many gotchas and rather error prone!

I believe there was a cppcon talk where the speaker said that it was a very common bug in Facebook, despite that they have linter rules to catch this case. Its also a rather insidious bug, because the code will run seemingly normally, just... it never actually locks anything. A rather hard problem to debug too.

[ Parent | on HN ]

Re:A Defer Mechanism for C by a1369209993 on Monday December 14, 2020 @09:04PM (#25426181)

> Its also a rather insidious bug, because the code will run seemingly normally, just... it never actually locks anything.

Actually, I think it's worse than that; IIUC, it will block until the mutex is unlocked, then run. Under light load, it will get away with this, but if the load is heavy enough, it will either guarantee that every process waiting for the lock runs at once, trampling each other's work, or almost-serialize them, making the race condition even more intermittent than if they didn't lock at all. Which failure mode you hit depends on how your scheduler works.

[ Parent | on HN ]

Re:A Defer Mechanism for C by gpderetta on Monday December 14, 2020 @01:05PM (#25420890)

yes, I think I hit it at least once and flagged I don't know how many times in code reviews.

[ Parent | on HN ]