| |||||||||||||
Btrfs aims for the mainlineBtrfs aims for the mainlinePosted Jan 7, 2009 21:32 UTC (Wed) by MisterIO (guest, #36192)Parent article: Btrfs aims for the mainline
Isn't it actually trying to acquire the lock for 513 times?
(Log in to post comments)
Btrfs aims for the mainline Posted Jan 7, 2009 23:21 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
I assume (but haven't checked) that the kernel's mutex functions do not have the 0 on success behaviour seen in pthread_mutex_trylock(3p)
Btrfs aims for the mainline Posted Jan 7, 2009 23:28 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
Oh, or did you mean 513 as distinct from the 512 claimed by the author? No, this is the usual C idiom for doing something N times...
for (int k = 0; k < N; ++k) { /* do something */ }
It won't do them N+1 times because after the Nth iteration k is N and will fail the condition (k < N)
(Actually mine is a slightly more modern idiom, requiring C9X semantics, and it has the K&R increment style, but it amounts to the same thing)
Btrfs aims for the mainline Posted Jan 7, 2009 23:25 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] Are you commenting on the fact that the loop iterates 512 times in addition to the one try outside the loop? The way I read the following, it tries once, and if it fails, it tries another 512 times: The lock in question is a mutex, but it is being acquired in an interesting way. If the lock is held by another process, this function will poll it up to 512 times, without sleeping, in the hope that it will become available quickly. Should that happen, the lock can be acquired without sleeping at all. After 512 unsuccessful attempts, the function will finally give up and go to sleep. So, yeah, it tries 513 times. I guess it's hair-splitting as to exactly how many times it tries. I think the point was "try several times just in case."
Btrfs aims for the mainline Posted Jan 8, 2009 4:16 UTC (Thu) by pr1268 (subscriber, #24648) [Link] Why not just get rid of the outer (top) if-statement altogether, and move the cpu_relax() statement to after the inner if-statement?
Btrfs aims for the mainline Posted Jan 9, 2009 17:57 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Why not just get rid of the outer (top) if-statement altogether, and move the cpu_relax() statement to after the inner if-statement? In at least some systems, it is probably an extra instruction or two for the most common case -- that the lock is available immediately. Lock algorithms are usually written this way. Incidentally, as long as we're counting, it's 514. mutex_lock_nested() will necessarily try to acquire the lock before going to sleep.
Btrfs aims for the mainline Posted Jan 8, 2009 4:25 UTC (Thu) by MisterIO (guest, #36192) [Link]
Yeah, I didn't mean to say I catched who knows what kind of big error, but if you sum the first attempt with the 512 into the loop, that's 513!
|
|||||||||||||