On Mon, 11 Dec 2006, Lars Hjemli wrote: > > But this also applies to the case where the cachefile has expired, > right? In that case, after getting the lock, I have to recheck that > the cachefile is _still_ expired. Yes. > Anyway, I must say I find it rather unlikely for these cases to occur > (frequently) in real life. That would seem to imply that the caching > isn't really needed at all. The point is, if you have races, you will hit them _occasionally_. It may not be a performance problem in real life, BUT: - quite often, you can take advantage of the serialization guarantees that a front-side cache offers you, and do the uncached accesses (or writing the final cache-file) knowing that there's only one thing that does that. - If so, then a race condition in the cache goes from a "unlikely performance problem" to a BUG. > > As a side note: how do you release your caches? > > Simple timeouts (time()-stat.st_mtime), depending on what kind of page > was requested. If anyone cares about invalid cache content (branch > head moving), relevant cachefiles can be deleted with an update-hook. I was more thinking about the locking part. Again, to be safe, you should probably take the lock before releasing any cache. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html