User: Password:
|
|
Subscribe / Log in / New account

C11 atomic variables and the kernel

C11 atomic variables and the kernel

Posted Feb 28, 2014 11:37 UTC (Fri) by khim (subscriber, #9252)
In reply to: C11 atomic variables and the kernel by jzbiciak
Parent article: C11 atomic variables and the kernel

Yes, bugs in compilers exist and should be fixed. Just like any other types of bugs. We don't design our programs around old bugs in kernel or libc, why should we design them to support broken compilers?

The rest of discussion sounds so bizzare I can not even believe I hear it on LWN. ALL remaining arguments only make sense for address-space constrained system without overcommit.

On systems with overcommit enabled and with no shortage of the address space (and that's 99.99% of systems out there) alloca is as safe as malloc+free and much, much faster. End of discussion.


(Log in to post comments)

C11 atomic variables and the kernel

Posted Feb 28, 2014 15:56 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Don't you argue that mobile devices are eating other form factor's lunches? They're all 32-bit last I checked where address space is at a premium.

C11 atomic variables and the kernel

Posted Feb 28, 2014 17:01 UTC (Fri) by khim (subscriber, #9252) [Link]

Don't you argue that mobile devices are eating other form factor's lunches?

Well, sure.

They're all 32-bit last I checked where address space is at a premium.

It's good idea to check things more often than once per decade. Have you head about this phone? How about this CPU or that one?

And I don't see where you get the notion that 32-bit implies “address space is at a premium”: typical mobile OS does not use swap and keeps many applications in memory at the same time. Any given application can only use 128MB or so. You can easily give allocate 16MB or 32MB of address space for heavy worker threads - more then enough for alloca.

C11 atomic variables and the kernel

Posted Feb 28, 2014 17:34 UTC (Fri) by jzbiciak (subscriber, #5246) [Link]

On platforms that support it. Still, it's not portable, and doesn't seem to offer truly material advantages in my eyes.

One place I've run into alloca() was in some initialization code of g_doom, the "generic frame buffer" port of Doom. That's pretty much the last place to make a "hot cache efficiency" or any other time-based argument for alloca() over malloc(). It was there pretty much for the purpose of getting an automatic deallocation if it took an early exit from the function.

The system I was porting to, however, didn't (and still doesn't) support alloca(), so I had to convert it to malloc()/free(). (And when I asked our compiler guys about it, they said "Just use malloc()" with the sort of tone that implied they thought alloca() was an abomination.)

Yes, the code was marginally cleaner looking with alloca(), but my point was that that benefit arises from the fact that C doesn't offer any other easy way to say "clean all this up when we leave this scope" other than to put things on the stack and rely on the stack frame unwinding.

Aside from non-portability, alloca() also pretty much requires you to use a frame pointer, since your stack frame size is now variable. Again, not usually a big deal, although it can hurt on register-starved architectures like 32-bit x86. And then there's all these fun comments in alloca()'s own manual page:

BUGS
        The alloca() function is machine and compiler dependent.  On many sys-
        tems its implementation is buggy.  Its use is discouraged.

        On many systems alloca() cannot be used inside the list of arguments of
        a function call, because the stack space reserved by alloca() would
        appear on the stack in the middle of the space for the function argu-
        ments.

I get it, you like alloca(). I see enough things potentially wrong with it that its meager advantages don't seem worth it to me.

C11 atomic variables and the kernel

Posted Feb 28, 2014 18:06 UTC (Fri) by khim (subscriber, #9252) [Link]

I get it, you like alloca(). I see enough things potentially wrong with it that its meager advantages don't seem worth it to me.

I'm not a big alloca lover, but I just don't see what's the big hoopla is all about. I mean: alloca is just a minor syntaxic sugar on top of facilities you have anyway. Yes, it's not portable but it's an interface people are familiar with, so why not?

Before you'll raise the racket about frame pointers and stuff please recall that you compiler must compile, e.g. the following program (from 6.5.3.4 The sizeof oprator part of the C standard):

#include <stddef.h>

size_t fsize(int n)
{
  char b[n+3];
  return sizeof b;
}

It's a 100% standard program. It's included in standard. It's non-optional part of it. It must be supported.

Now on any system where it's supported alloca implementation is trivial, so why not just implement and use it where appropriate?

I'm yet to observe a system which supports the aforementioned program (from the official 15 years old standard - and included again in new C11 one, too!) which does not support working and usable alloca and if you insist on using broken tools you deserve to receive broken programs.

P.S. Note that function in standard is called fsize—this gives you pretty strong hint where and how such facilities are supposed to be used, right?


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds