[9fans] locking

[9fans] locking

[Steve Simon]

Hi,

I have a problem on an OS, its not plan9 but similar,
so I thought I would ask here.

Say you have a synthetic file which you use to query
the state of a subsystem, a plan9 example might /net/dns,
my example is reading a port in an fpga.

I want to run this multithreaded, but the requests
and replies are not atomic on the same file descriptor.
Thus I need to have each thread request on its own file
descriptor, or, have a Qlock in the requesting program
to interlock requests and replies.

Now the fun.

Some requests can take a long time (hours) so the Qlock
is inpractiable, though adding a open per thread is also
a pain.

When I get problems like this I usually think "how would I
do this on plan9", and the only answer I can come up with is
to have a single ioproc doing the device access and a load of
threads in another proc making requests.

Anyone think of a technique I have missed?

-Steve

Re: [9fans] locking

[Russ Cox]

> I want to run this multithreaded, but the requests
> and replies are not atomic on the same file descriptor.
> Thus I need to have each thread request on its own file
> descriptor, or, have a Qlock in the requesting program
> to interlock requests and replies.

does the synethetic file protocol have request ids so that
it can allow multiple outstanding requests
and can send replies out-of-order?

if so, then you need only multiplex the requests onto
the synthetic file.  see libmux in the p9p distribution
for a simple encapsulation of the relevant logic.

if not, then you really need one fd per active request.
you could use a cache of already-opened fds; 
that would only grow to the number of active requests,
not the number of threads.

russ

Re: [9fans] locking

[Steve Simon]

> does the synethetic file protocol have request ids

I'am afriad not, and the overhead of matching IDs would be too great.

> you could use a cache of already-opened fds; 
> that would only grow to the number of active requests,
> not the number of threads.

I like this though.

I admit I have since found a really ugly solution that is too
vile to describe, it's saving grace is it's speed. However I
will try opening new fds on demand when I get a chance, its
probably nearly as fast and nothing like so embarrasing.

-Steve