lkml.org 
[lkml]   [1996]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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



\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.082 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site