* [9fans] locking
@ 2007-04-18 12:24 Steve Simon
2007-04-18 16:35 ` Russ Cox
0 siblings, 1 reply; 3+ messages in thread
From: Steve Simon @ 2007-04-18 12:24 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [9fans] locking
2007-04-18 12:24 [9fans] locking Steve Simon
@ 2007-04-18 16:35 ` Russ Cox
2007-04-18 23:10 ` Steve Simon
0 siblings, 1 reply; 3+ messages in thread
From: Russ Cox @ 2007-04-18 16:35 UTC (permalink / raw)
To: 9fans
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [9fans] locking
2007-04-18 16:35 ` Russ Cox
@ 2007-04-18 23:10 ` Steve Simon
0 siblings, 0 replies; 3+ messages in thread
From: Steve Simon @ 2007-04-18 23:10 UTC (permalink / raw)
To: 9fans
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-04-18 23:10 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-04-18 12:24 [9fans] locking Steve Simon
2007-04-18 16:35 ` Russ Cox
2007-04-18 23:10 ` Steve Simon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).