On Wed, Jan 13, 2010 at 07:33:22PM -0600, Shawn Walker wrote: > >I'm trying to discern the use for the image's NRLock in this situation. > >If the install/image-update -nv can't modify the image, is it necessary > >for the client to hold this lock without making use of flock? Would it > >be better to instead set a read-lock with flock in this case? > > So the idea was to minimally lock. That is, only lock for write > operations. The point of using the NRLock() is simply to prevent > multiple locks of the same image object due to broken/bad logic > within the same process. In short, one operation at a time using > the image object.
If you're trying to prevent concurrent access to the image object by the same threads in the process, it sounds like you're duplicating a lot of the functionality of the API's activity lock. Would you look at how the functionality of the activity lock and the image lock can be commonized? I think that the activity lock may be redundant if you're using the image's NRLock to serialize. > >>I'm still not convinced that there isn't value here in the timeout > >>logic. Since the logic here is nearly identical to that used by > >>python's own mechanism for threading conditions, couldn't the same > >>problems happen? > > > >I don't understand why the timeout is necessary. Either the caller > >wants to grab the lock and is willing to wait its turn, or the caller > >wants to try the lock and return a suitable error message if it is > >already locked. The timeout doesn't do application code any good, since > > Even if I took the approach of "wait" or "don't wait", how do I > ensure callers have control over how long to wait without doing > this? What caller needs control over how long to wait? I tried to lay out the cases where I thought this lock might get contended, but there didn't seem to be a plausible explanation for a timeout. Either the caller needs the lock and must wait, or the caller doesn't want to wait and should return. What's the use case for a timeout for the API's consumers? > >there's no way to know how long an operation might take. A user who > >wants to install now, immediately, should not block so that corrective > >action can occur as soon as possible. A user who is willing to wait for > >a pending operation to complete can't know the time and must simply > >block. What value am I missing? > > Because this is a generic API thing and I don't know how long > different clients for different applications feel it is appropriate > to block for a lock. I would prefer that we don't give clients the option. Let them keep it simple. mutex_lock(3C), mutex(9F), semaphore(9F), semaphore(3C), and pthread_mutex_lock(3C) all support lock, unlock, and trylock. There's no timeout, except for condition variables which are a different type of syncrhonization object. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
