Robert Collins wrote:
> Well lets say I have 10 disks, with 16 threads each. That's up to a 160
> times I might have to repeat that timed wait to get a lock. There are
> probably better aproachs out there... but I'm new to coding multi
> threaded apps vs reading and thinking about em, so again I'll defer to
> the gurus...
Does not work quite that way. I/O threads should normally be blocked,
either waiting for requests to arrive on the queue or making I/O. In
neither of these states the I/O thread is a burden for the queue lock.
It does not actually matter that much how many threads you have, what
matters is how often these threads polls the queue. Each poll is as
Kevin said very short in time, but still there might be a context-switch
or other blocking operation while the lock is held, causing problems for
the main thread.
Yes, the duration will most times be quite short, but still there are
odd situations where the effect might be multiplied due to context
switching and CPU usage..
/Henrik
Received on Sat Mar 17 2001 - 06:28:28 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:38 MST