Messages in this thread | | | Date | Fri, 12 Apr 1996 23:38:02 +0100 (BST) | From | Philip Blundell <> | Subject | Re: Simple resource synchronisation |
| |
On Thu, 11 Apr 1996, Grant R. Guenther wrote:
> A more dynamic high-level resource synchronisation mechanism > might be preferrable. How about a pair of higher-level operations > something like: > > claim_resource( char *resource, void (*preempt)(void), int priority ) > > free_resource( char *resource) > > where the resource is an arbitrary _symbolic_ resource name ? The semantics > should be obvious, but we would have to spell them out carefully.
This could work. It would probably be as well to allow a driver to refuse to be pre-empted, in which case the claim would fail. You would have to allow for a claim failing anyway, to cater for old non-sharing-aware drivers that just do a request_region() and sit on the port. If pre-emption fails, you can schedule a later retry -- this might happen, for example, if the PLIP driver was in the middle of sending a frame, and pre-emption at that moment would be undesirable. If your driver is itself in a situation where failing to grab the port is disastrous, it shouldn't have released it in the first place.
I'm not sure that a priority system is needed, either. It's really only sensible to have one driver (like, say, PLIP) that lurks in the background grabbing the port when nobody else wants it. If you try to start another driver like this, you're in a losing situation and things are entitled to refuse to happen. With drivers that only run in the "foreground" as it were, and only want the port transiently, again there doesn't seem to be much call for priorities. If a driver has the port, it seems best to let it keep it as long as it wants. Although you *could* claim that it would be useful for a driver to declare that it has a higher priority, I don't think it would help us very much. It's possible that you might need this to avoid deadlock, but I don't think so.
> Now there are some obvious performance weaknesses with this symbolic > approach, but I think it has the kind of generality that one wants in > a feature of the kernel proper.
Mmm. I'm not sure that a symbolic name is needed, but it doesn't cost much, and might be good to have. Performance probably isn't that big an issue -- parallel ports aren't blazingly fast anyway, and people can probably live with the idea that things will slow down if they have to multiplex them between drivers. Unless you're on a laptop, adding an extra parallel port is a fairly trivial matter anyway.
> Can anybody think of a better way to do this ?
Not really. You could consider making it look a bit more like the current resource manager, and abandoning the symbolic approach. This would give you something like:
int request_shared_region(unsigned long start, unsigned long extent); int claim_shared_region(int handle, int (*preempt)(void)); void free_shared_region(int handle);
... where request_shared_region() takes the region you want to claim, and gives you back some arbitrary handle to it. If this is the first time the region has been claimed, it would do a request_region() to stop anybody else trying to grab it exclusively. The advantage over your idea is that you don't have to do your own request_region() and free_region() calls every time, but the disadvantage is that you lose generality.
P. -- .signature: Permission denied
| |