Thursday, April 2, 2009

What I learned today.

I've noticed that SW designer's job is constant learning. If you stop learning, tou stop advancing. For a newish guy on the field like me, most of the learning is related to existing systems - but even the old chaps need to keep making progress, new technologies keep coming, and falling back means giving advantage to others.

So, I guess I'll start writing down this "What I learned today" post, in which I try to add new comments ehen I have learned something new. Just short sentences, with no long background, but with some information that was new to me.

But since I started this now, not at my first day in the job, I'll write down a couple of things in this post too :)

Last December.

Untill the really latest glibc versions, there's a bug in glibc's timer_create() function implementation, which may cause a crash under certain conditions. (When timer expires, attempt to read the internal list where timers are kept in glibc, may access to invalid memory location)

A few months ago.

Helgrind is yet another great tool built on valgrind.
(It can be used to detect synchronization issues in multithreaded applications - although it has it's limitations)

A few weeks ago.

In some glibc versions for powerpc have a bug, which makes valgrind yelling a lot of false alarms!

A few days ago.

pthread's stack size cannot be easily (or portably) changed after the thread is created.

(It can be set during the thread initialization. It is not really common to have real need for changing the default stack size [actually this sounds like terribly failed design], but there may be cases where one needs to create many [read some hundreds of] threads with limited virtual address space [*shrugs*]. On linux at least, the real memory is not used more than really required, but virtual address space will be reserved for whole threads stack (no matter how much the thread really needs the stack).

Today: (02.04.2009)

In most linuxes, there's a program called "yes" included, which will repeatedly print the text given as argument. My co-worker told that to me today, and I used it to generate some CPU load when I needed to do some performance analysis. I used:

yes Matti > /dev/null
renice -19


  1. 07.04.2009

    Today I learned that on x86 it is quite simple to create atomic compare and swap function, using inline asm. I was puzzled by question, "how to return the value read from memory before the swap is done". Idea was to use x86 asm instruction cmpxchgl, which will do the swap. I knew I could use the return value to indicate whether the swap was done if I did the function as:

    int __INLINE__ atominenCAS( int *ptr, int cmp, int new)
    unsigned char ret;

    __asm__ __volatile__ (
    " lock\n"
    " cmpxchgl %2,%1\n"
    " sete %0\n"
    : "=q" (ret), "=m" (*ptr)
    : "r" (new), "m" (*ptr), "a" (cmp)
    : "memory");

    return (int)ret;


    But problem was that I wanted to return the old value of *ptr. So, how to do storing of original value and the CAS atomically - without locks? After I pondered this over the weekend, I asked from my co-worker, who pointed me the section in intel manual, telling that cmpxchg does store the value read from memory, to register where the cmp was read from. So with a lil modifications, I was able to just return the value of cmp. If swap did not succeed, cmp contained value read from memory - if it did succeed, then the cmp did already equal to value read from memory. Hence returning cmp was always correct :)

  2. 09.04.2009
    Today I learned that many files in linux /proc folder do not contain data all the time. Many of those are created in such a way, that when read() is issued to a file, it actually triggers some operation in kernel, which will provide the data.

  3. 15.04.2009
    I have read it from references. I've been told so by many persons. I've believed in it. But today my world turned upside down ;)

    Today I learned that in procps package, in top command's implementation, there is:

    fp = fopen("/proc/stat", "r")

    All documentation I've read concerning fflush(), states that fflush() should only be used with output streams. The ANSI C standard leaves fflushing input streams undefined. However it seems that in top implementation, file opened for reading is fflushed.

    Allright. My expertice is not deep enough that I could say this is wrong, but somehow it still smells. I can however live with this information, because it is /proc/stat which is opened. As we know, things are a bit different in /proc/. Often calls issued to /proc/* do not actually operate quite like on regular files - they usually invoke some operation in kernel. So perhaps there is some twisted hook in there :) But anyways, if anyone can shed some light on this, I am keen to learn!

  4. 04.05.2009
    Today I found a new cool thing from my version of gdb which came with the distro I have at home. I do not know if plain vanilla gdb has this, or if this is some additional feature, but when I typed

    layout src

    I got nice splitted window where top part held the source view where line being executed was hilighted. With

    layout asm

    I got similar view, but now instead of C code (or C source files) I saw asm code.I bet the asm code can be shown even when no debuginfos are enabled.

    Leaving the "asm layout" or "src layout" was tougher call. I could not find anything usefull from gdb helps, and ended up googling.

    "gdb leave layout src" "gdb quit layout src" "gdb leave layout src window" "gdb quit layout src window" and so on did yield results I did not want to see. But finally I found the answer. Keyword to use when searching for information about these windowing is TUI. This woindowed mode is TUI mode, and it can be left using key combination

    ctrl+x A

    But all in all, this feature was cool, and worth of checking out. I am more and more in love with gdb :)

  5. i was searching the keyword about diary, programming/programmer. and the search engine brings me here. it seems quite some time you did not keep your good habit. haha.