Friday, November 09, 2007

Re: "C and multithreading"

On debian planet. I read the C and multithreading post of Miriam Ruiz, but I don't agree with some conclusions:

First of all, I don't agree with Linus. C standard doesn't allow such optimizations. One of the driving point of C standard (and thus C) is that compiler should do what a programmer write, without much optimization, i.e. C should remain a low level language. It was iterated also for the principles of new C1X standard.

Second point. Volatile is not the right solution. volatile means that a variable should be read every time it is accessed, so the variable should not be but in registers (remember the nearly obsolete register keyword).

The problem of multi threading is not only that variables could changes (but this is a fact also of
single thread programs, when you write a signal handler [which are specified in C standard and which are handled correctly]), but for semaphores there are "barriers", i.e. you should not move read or write across such barriers.

What do volatile have with barriers? Nothing. If you read the standard (you can check also only the one page C appendix), you see that C specify what are the "standard" barrier, and they are nearly in all obvious points (i.e. a ";" is also a barrier), so moving instructions is "illegal" for C.
Ok. volatile had few other barriers, but across ";" there is already a barrier, so volatile is not the solution of barrier problem (AB locking).

References: see C wiki and C standard.

Thursday, November 01, 2007

Linux Kernel Driver DataBase

This weekend I finally finished the Linux Kernel Driver DataBase . Really I started this project in 2000, but in 2001 after some flames in the LKML (for CML2, the configuration engine used by my project) I put the project in a long hibernation. Now I had some time to finish it.

LKDDb is a database of hardware (and protocols), kernel configuration items and associated kernel driver files. Actually it has nearly 6000 entries (see the statistics). The database is generated automagically, quite fast: it take 2 minutes to scan the whole kernel source, and to interpret it. Unfortunately it is not complete and not accurate (I'm not sure if there is some black-list in kernel, but my scanner cannot distinguish the black-list with the supported hardware list).

Now I'm looking for some application of the database. In 2001 it seemed that there was some interest, but let see.

As a prototype, I dis-hibernate also the AutoKernConf, an automagical kernel configuration. The old version was a more powerful, so I need to forward-port some old features. BTW I changed an other time the project name: autoconfig was too similar to existing projects, kautoconfig, kernfig, kernautoconf were other names, but I like better the new name, and I can use the automagical word in the description ;-)

Do you see other uses of the database?