Re: FileManager Performance on OSX
Re: FileManager Performance on OSX
- Subject: Re: FileManager Performance on OSX
- From: kelly jacklin <email@hidden>
- Date: Fri, 4 Jun 2004 06:45:18 -0700
On Jun 4, 2004, at 6:13 AM, Kent Clelland wrote:
On Jun 3, 2004, at 9:47 PM, email@hidden
wrote:
According to one of the authors of the Carbon File Manager, async
reads
are no better than synchronous reads on X.
is this really true?
or to what extent is this true? OR what means "BETTER"??
does this mean that async reads are not async on X?
What is true is that all Carbon async I/O from a process is serialized
with respect to other Carbon async I/O in that process. Thus issuing 5
async I/O requests to 5 different devices from a single app results in
5 serialized I/Os. The only things that are "async" about them is that
they do not occur on the main thread (or whatever thread issued them,
unless from an IOCompletion) and that making the {PB,FS}*Async call
does not block until the request is complete.
Note that not only I/O requests are serialized, but all other
{PB,FS}*Async requests are as well. As you can see if you look at the
threads in your app in the debugger, there is a single AsyncFileThread
created by Carbon that handles all of the async FileMgr requests.
Making one of these async calls enqueues the request on a queue that is
serviced by this FileMgr thread.
If you want true asynchrony, you cannot get it from the Carbon
FileManager today (this may change in the future). Note (carefully)
that the behaviour described in this e-mail is subject to change, and
is provided for informational purposes about the current (last time I
looked, anyways) functioning of the Carbon FileMgr...
if I have an app which has 15 - 20 threads running around doing their
thing, one of those threads is responsible for reading data from disk.
5 other threads are blocked until the read thread is completed. if I
read async I would imagine that the amount of time that the 5 threads
are blocked is minimized. the data may not yet be ready, but the
threads shouldn't hang up waiting for a sync read operation to finish?
OR????
I sure don't get this statement. Just because one thread is blocked on
a read from the disk doesn't mean that the other threads in your app
are blocked. Unless they are waiting for the read to complete (via a
condition variable, semaphore or other blocking construct), they are
completely unaffected by the fact that the reading thread is blocked on
a disk I/O...
while we're on the topic of filemanager...
I want to ask also about WRITING (streaming) data to disk..
I've noticed that the async calls (PBWriteAsync) perform much better
(ie don't interrupt audio)
than the other write methods, even when boundary-ing on 4k blocks,
pumping up thread priorities, etc...
so the question is WHY?
Because they defer to another thread to do the processing (see above).
Of course you would never (_ever_) block the IOProc by making a call
into the OS to do I/O on that thread, but would instead defer to
another thread to do the I/O, so I'm not sure why you are seeing a
difference in performance.
Of course if you were directly invoking synchronous filesystem calls
from the IOProc, then switching to the async versions would be faster
(and would cause your app not to stutter), but even making async
FileMgr calls can block (when there is contention for the queue
mentioned above), so even this is not a good idea (IMHO). You would
best be served by writing your data to a ring buffer, notifying a
service thread (via something non-blocking like mach semaphores), and
having it do all the I/O calls.
and actually file io on X has become quite mysterious, no? I mean
when one is confronted with choosing between
fwrite
FSWrite
FSWriteFork
PBWriteSync
PBWriteAsync
one would imagine that at some point they would all get patched
through to a single call, no?
Yes.
and is that not actually a
PBBlah() call?
No (eventually everything boils down to underlying Darwin calls, like
the POSIX write/pwrite calls).
docs are a little skimpy in this regards...
As they should be. The internal implementation of the Carbon FileMgr
is not documented anywhere that is accessible to developers. If Apple
fully documented the implementation of the Carbon FileMgr, then someone
would write code that depends on those implementation details (rather
than the behaviour of the API), and Apple could not improve it in the
future without breaking that dependency, and potentially breaking the
app that has that dependency...
Is there some specific issue you are trying to solve?
kelly jacklin
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.