Btrfs aims for the mainline [LWN.net]

Btrfs aims for the mainline

Posted Jan 7, 2009 23:25 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246)
In reply to: Btrfs aims for the mainline by MisterIO
Parent article: Btrfs aims for the mainline

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."

(Log in to post comments)

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!