Re: Singleton_pattern and Thread Safety

From:

Joshua Maurice <joshuamaurice@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Thu, 16 Dec 2010 16:24:56 -0800 (PST)

Message-ID:

<ee62c226-c377-4930-a098-a2c48b6426c0@r16g2000prh.googlegroups.com>

On Dec 16, 5:51 am, Leigh Johnston <le...@i42.co.uk> wrote:

On 16/12/2010 03:05, Joshua Maurice wrote:

On Dec 15, 6:02 pm, Leigh Johnston<le...@i42.co.uk> wrote:

You say Apple disagree with me on the definition of a leak? From th=

same page you linked:

"If you call malloc or any routine that allocates memory, you must
balance that call with a corresponding free."

End of discussion.

I'm trying to tease out what you really think. You presumably don't
think that "Leigh Johnston memory leak" must be avoided at all costs -
at least, I hope that.

Namely, do you call abort or use assert from anywhere but the end of
main with zero outstanding mallocs, news, etc.? Do you use the C
library, such as glibc, or whatever windows equivalent? I'm willing to
bet that there are memory allocations in there with no paired free
calls. Moreover, have you ever written for a POSIX system ever? That
requires the use of fork and exec (perhaps indirectly), which almost
certainly requires a "Leigh Johnston memory leak" for any use
whatsoever.

So, as you have written working code, I can assume that in some
contexts "Leigh Johnston memory leaks" are ok, such as the ones listed
above. Please stop me if you disagree, and please describe your
problems with my analysis thus far, because I would be quite lost if
you did disagree.

So, is it just that "Leigh Johnston memory leaks" which are under your
control must be prevented at all costs, and you make do with the
mistakes of others who wrote the C library, fork and exec, etc.? IMAO,
this would be rather pants-on-head retarded if you said yes here. I
would read a yes as: "The C library on all platforms has memory leaks,
but programs written against it do not run out of virtual space, nor
does the OS run out of commit space."

I really do like the libc example. libc is an excellent example of a
library which the writers know will be loaded at most once per
process. If some process attempts to load it multiple times, then all
bets are off. I think I agree with others that this appears to be the
sensible default position, and shared-objects which are loaded and
unloaded multiple times in a single process are more of a special case
which deserve special care. I'm not entirely satisfied with this
result, but the alternative appears to be to take issue with all win /
mac / unix implementations in existence which display no visible bugs,
which I also don't feel comfortable doing.

This almost feels like I need to invoke "Worse Is Better". I need some
time to think about how I would apply "Worse Is Better" to this
conversion, but it feels right to do so. A gut feeling if you will.

The C library on all platforms has memory leaks? Prove it.

I strive to write leak free code for any definition of leak. As I have
already said Microsoft agree with me on the definition of a leak so it
is not a "Leigh Johnston memory leak" but a "memory leak". End of
discussion.

Curious. I jumped to conclusions. I just tested it on my linux box.
Repeated loading and unloading of libc and the c++ std lib does not
result in increasing process size. I was wrong.

Test code:

  //foo.c
  int main();
  void _start()
  {
    main();
    asm("movl %eax,%ebx");
    asm("movl $1, %eax");
    asm("int $0x80");
  }

  #include <dlfcn.h>

  int main()
  {
    for (;;)
    {
      void* libcpp = dlopen("/usr/lib64/libstdc++.so.6", RTLD_NOW |
RTLD_GLOBAL);
      if ( ! libcpp)
        return 7;
      if (dlclose(libcpp))
        return 8;
  }

Compile and link command:
  gcc foo.c -nostdlib -lgcc -ldl

In another test (not shown), I even malloc-ed a piece of memory with
malloc from dlsym, then free-ed it with free from dlsym, once per
loading of libc, in a tight loop. Again, no increase in process size.
This is most interesting.