From: Jan-Benedict G. <jb...@lu...> - 2009-12-27 12:55:39
|
On Sun, 2009-12-27 12:59:30 +0100, Stef Bon <st...@gm...> wrote: > > I've got to mention that I personally do not like constructions like: > > path_copy=strdup(path); > if ( ! path_copy ) { ....} > > I understand what's happening here, and I've seen it often in C (and > even bash) programm's, and it's a check > path_copy is defined, but it looks like it a check as if it's boolean > (and false) which is not the case. > > Better would be imho : > > if ( path_copy != NULL ) { ..... } It's longer--and it's exactly the same. > This is correct and has the same effect? It is exactly the same, probably the compiler will even generate the exact same binary code. However, it's longer and by convention, about every C coder will use the shorter form. > the about locking. I've seen program's using this pthread_lock call. > This is logical and complicated at the same time for me. Is this > necessary in Fuse modules? Maybe not right now. But if you write really good code, you separate functions by the problems they're solving into different source files. Thus, this *very* function may not need any locking while being attached to your current FUSE development. But what, if this source file is copied to another project--which uses threads a lot?! Better think about it now. If you know that for this fuse project, you don't need locking, put it into ifdefs or conditinal variables (in both cases, it'll be either not compiled in in the first run, or optimized out afterwards.) But keep the /problem/ in mind. > But here, when doing in the function > > path_copy=strdup(path); > basename_part = basename(path_copy); > > The vars path_copy and basename_part are unique for a thread, and not > used or mixed in any way between threads, right? But as you write in Right. As long as they're "automatic" variables, placed on the stack. > your reply, it's the function basename which may overwrite static > memory. So as I understand basename may overwrite things, right? Is > this what they call "not multi thread safe"? Is there a list of > function calls of some sort which are not multi thread safe? Exactly! `basename' is not MT-safe. It *may* have some static local memory, write to it and return a pointer to it to it's caller. If now, in a multi-threaded environment, another thread calls basename at about the same time, the second invocation may write something different to that internal memory--to which the first caller just got a pointer returned! First caller might see the new content, without knowing that it changed since his call. This is why you serialize (with locks) calls to non-MT-safe functions, save their results away and open the lock again. > And the name of the lock (basename_dirname_mutex) should be the same > of course in the whole multi thread program? It's not about the /name/. Each source file could have: static pthread_mutex_t foo; That means that there are /several/ "foo"s, which share a name, but nothing else. (Especially not their locking functionality.) You have to use _one_ common lock for each function (or group of function) that share _one_ common property. (Think about getpwend/setpwent/endpwent.) MfG, JBG -- Jan-Benedict Glaw jb...@lu... +49-172-7608481 Signature of: GDB has a 'break' feature; why doesn't it have 'fix' too? the second : |