Jim Rees wrote: > well, you can but you need to call h_Lock(host) and not h_Lock_r(). > > Yes, but no one does. > > I think my next step is to rationalize the locks so that H_LOCK is only (and > always) used to protect the hash table, and h_Lock is only used to protect > the host entry. I think the order should be the other way around, too. > With the current code the host could disappear when you drop H_LOCK so you > can get h_Lock. Unless it's always held (refcounted), which I'm not sure is > the case.
Quoting Jeffrey Hutzelman: "Bear in mind that the point of h_Lock_r is to _allow_ us to acquire a host lock while holding H_LOCK, not to _require_ it. All of the *_r routines are 'while I'm already holding the relevant lock'. So if you don't have H_LOCK, then call h_Lock instead of h_Lock_r, and it's all good. "Of course, the normal assumption here would be that H_LOCK is indeed above the individual host locks in the heirarchy, such that you must be holding H_LOCK (since otherwise the hash table could change out from under you). In such a case, h_Lock_r would do the real work, and h_Lock would be a wrapper which temporarily acquires the H_LOCK. But that's obviously _not_ what's happening here."
smime.p7s
Description: S/MIME Cryptographic Signature
