Of the mechanisms discussed, I am not sure I understand what you mean by async I/O with only one thread. I can imagine a nonblocking/select style approach that has no extra threads, but as soon as the main thread is not waiting on I/O itself (my interpretation of "async"), there needs to be threads to do the waiting. Unless I am missing something (which happens often<g>) or we are having terminology problems (also a frustratingly frequent occurrence). Best, Don --- Caleb Epstein <caleb.epstein@gmail.com> wrote:
I'd say coupling asynchronous I/O to multi-threading would be a mistake. It is at its most useful IMHO in single-threaded cases.
-- Caleb Epstein caleb dot epstein at gmail dot com
__________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Windows has the concept of "Overlapped I/O" which permits dispatch of an i/o request that invokes a call back when done. Posix has aio which functions (I believe) in a similar way. So one has the concept of asyncronous i/o without any explicit reference to threads at least at the application level. In one I my projects I had occasion to use this. The windows API I found to be (as usual) pretty unwieldy. I ended implementing a wrapper with the aio interface. So it does work and can be useful. On the otherhand, it does seem to me functionally equivalent to multi-threading which is a more general and perhaps simpler concept. So it may or may not be a good idea to encourage its usage as opposed to threads Robert Ramey Don G wrote:
Of the mechanisms discussed, I am not sure I understand what you mean by async I/O with only one thread.
Robert Ramey wrote:
Windows has the concept of "Overlapped I/O" which permits dispatch of an i/o request that invokes a call back when done.
Posix has aio which functions (I believe) in a similar way.
So one has the concept of asyncronous i/o without any explicit reference to threads at least at the application level.
I am not sure if I understand correctly. Just as Don I think we can't get around threads when we have callbacks. I don't know about Windows but the callback in aio (Posix) is done by creating a new thread. Boris
Boris wrote:
Robert Ramey wrote:
Windows has the concept of "Overlapped I/O" which permits dispatch of an i/o request that invokes a call back when done.
Posix has aio which functions (I believe) in a similar way.
So one has the concept of asyncronous i/o without any explicit reference to threads at least at the application level.
I am not sure if I understand correctly. Just as Don I think we can't get around threads when we have callbacks. I don't know about Windows but the callback in aio (Posix) is done by creating a new thread.
From the Microsoft documentation of ReadFileEx (a Windows API function):
"If the function succeeds, and the file reading operation completes, but the calling thread is not in an alertable wait state, the system queues the completion routine call, holding the call until the calling thread enters an alertable wait state." Very simply the calling thread starts off the read operation, and then either polls the i/o state or waits. In that wait operation lies the call to the i/o completion routine (the callback), which is called on this thread.
From the caller's point of view there's only one thread.
However, the abstraction involved in waiting on completion is the same as waiting for a thread, so the i/o operation is perhaps best modelled as having at least part of the interface of a thread (but this just gut feeling).
On Tue, Mar 29, 2005 at 04:36:42PM +0300, Boris wrote:
Robert Ramey wrote:
Windows has the concept of "Overlapped I/O" which permits dispatch of an i/o request that invokes a call back when done.
Posix has aio which functions (I believe) in a similar way.
So one has the concept of asyncronous i/o without any explicit reference to threads at least at the application level.
I am not sure if I understand correctly. Just as Don I think we can't get around threads when we have callbacks. I don't know about Windows but the callback in aio (Posix) is done by creating a new thread.
How the kernel chooses to implement the aio system calls is an implementation detail - it certainly doesn't require use of Boost.Thread types! I think what Robert was saying is that an application can use POSIX aio without ever having to use or know about POSIX threads. You and Don seem to be requiring that the application explicitly create and manage threads. Several people have suggested they'd like to use some form of AIO without having to use threads. jon
Well put !!! I have in fact implemented the aio interface in terms of windows API calls. Aside from the fact that the windows API in this area is a little "inelegant" it actually mapped quite well to the aio interface. When I was faced with the problem of adding async i/o to my application, and not wanting to make my application windows specific, I came upon aio.h. I implemented it in terms of windows API calls and got things working to my satisfaction. Afterwards, I believe I built and tested my app on a *nix system with aio. If I recall correctly, it worked as I hoped it would. To this day I have no idea how aio was implemented on a freeBSD machine. I doubt it added threads to my ap - though I can't say for sure. It might have relied on some lower level os API or it might have had native support at the OS level. So - it seems that if wants to use aio.h - its already there for atleast some *nix systems. If one want's to make it universal it can be implemented for Win32 systems. For other *nix systems it could be implemented in terms of threads. Robert Ramey Jonathan Wakely wrote:
On Tue, Mar 29, 2005 at 04:36:42PM +0300, Boris wrote:
Robert Ramey wrote:
Windows has the concept of "Overlapped I/O" which permits dispatch of an i/o request that invokes a call back when done.
Posix has aio which functions (I believe) in a similar way.
So one has the concept of asyncronous i/o without any explicit reference to threads at least at the application level.
I am not sure if I understand correctly. Just as Don I think we can't get around threads when we have callbacks. I don't know about Windows but the callback in aio (Posix) is done by creating a new thread.
How the kernel chooses to implement the aio system calls is an implementation detail - it certainly doesn't require use of Boost.Thread types! I think what Robert was saying is that an application can use POSIX aio without ever having to use or know about POSIX threads.
You and Don seem to be requiring that the application explicitly create and manage threads. Several people have suggested they'd like to use some form of AIO without having to use threads.
jon
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jonathan Wakely wrote:
On Tue, Mar 29, 2005 at 04:36:42PM +0300, Boris wrote:
Robert Ramey wrote:
Windows has the concept of "Overlapped I/O" which permits dispatch of an i/o request that invokes a call back when done.
Posix has aio which functions (I believe) in a similar way.
So one has the concept of asyncronous i/o without any explicit reference to threads at least at the application level.
I am not sure if I understand correctly. Just as Don I think we can't get around threads when we have callbacks. I don't know about Windows but the callback in aio (Posix) is done by creating a new thread.
How the kernel chooses to implement the aio system calls is an implementation detail - it certainly doesn't require use of Boost.Thread types! I think what Robert was saying is that an application can use POSIX aio without ever having to use or know about POSIX threads.
But the application programmer still must understand that the callback function is executed as a thread as otherwise he could mess up everything if he believes his application is single-threaded.
You and Don seem to be requiring that the application explicitly create and manage threads. Several people have suggested they'd like to use some form of AIO without having to use threads.
I think Don and me were talking about callbacks where we think they can't be implemented without threads. However I don't mind if the library creates and manages threads. If we don't use threads for callbacks the one and only thread in the application has to wait or poll - this is possible eg. in .NET which is very flexible about asynchronous operations (see http://blogs.msdn.com/cbrumme/archive/2003/05/06/51385.aspx). However if you want to wait or poll you don't use an asynchronous model at all but just do non-blocking calls or block in a select() (multiplexing model). Maybe the confusion comes from that I have a network library in mind and others think about asynchronicity in general? Boris
I refreshed my memory re aio.h and found it uses no callback. aio_read Start an asynchronous read operation aio_write Start an asynchronous write operation lio_listio Start a list of asynchronous I/O operations aio_suspend Wait for completion of one or more asynchronous I/O operations aio_error Retrieve the error status of an asynchronous I/O operation aio_return Retrieve the return status of an asynchronous I/O operation and free any associated system resources aio_cancel Request cancellation of a pending asynchronous I/O operation aio_fsync Initiate synchronization of the media image of a file to which asynchronous operations have been addressed The question here is: iIs aio.h interface not sufficient in some way? If not, what facility is it missing? If it is sufficient, then just depend on the available implementation or re-implement the interface in the most convenient way. Robert Ramey Boris wrote:
I am not sure if I understand correctly. Just as Don I think we can't get around threads when we have callbacks. I don't know about Windows but the callback in aio (Posix) is done by creating a new thread.
Robert Ramey wrote:
I refreshed my memory re aio.h and found it uses no callback.
aio_read Start an asynchronous read operation aio_write Start an asynchronous write operation lio_listio Start a list of asynchronous I/O operations aio_suspend Wait for completion of one or more asynchronous I/O operations aio_error Retrieve the error status of an asynchronous I/O operation aio_return Retrieve the return status of an asynchronous I/O operation and free any associated system resources aio_cancel Request cancellation of a pending asynchronous I/O operation aio_fsync Initiate synchronization of the media image of a file to which asynchronous operations have been addressed
Please have a look at struct aiocb. A pointer to this struct is passed to the functions you have listed above. It has a member called aio_sigevent which is of type sigevent. This is another struct which has a member called sigev_notify_function which is of type void(*)(unsigned sigval). If you use POSIX aio there is either a signal generated or a function called as a thread.
The question here is:
iIs aio.h interface not sufficient in some way? If not, what facility is it missing? If it is sufficient, then just depend on the available implementation or re-implement the interface in the most convenient way.
I am not sure if we are still talking about asynchronous I/O or asynchronicity in general as things seem to get mixed up? Boris
Don G <dongryphon <at> yahoo.com> writes:
Of the mechanisms discussed, I am not sure I understand what you mean by async I/O with only one thread. I can imagine a nonblocking/select style approach that has no extra threads, but as soon as the main thread is not waiting on I/O itself (my interpretation of "async"), there needs to be threads to do the waiting. Unless I am missing something (which happens often<g>) or we are having terminology problems (also a frustratingly frequent occurrence).
You should take a look at the python Twisted framework <http://twistedmatrix.com/>. There are performance issues in python with threads because of the Global Interpreter Lock (GIL). The framework is a workaround, performing every task in an asynchronous way from a single thread. The design of the Defer class is interesting and is the key of asychronous tasks control flows (<http://twistedmatrix.com/projects/core/documentation/howto/defer.html>). By the way, there were and will be lengthy discussions about which approach is the "best" to build scalable concurrent programs. I think that multithreading and event-driven programming were proven to be equivalent from a theorical point of view, but there real differences in implementation. You could read this one and many items from its bibliography too: <http://capriccio.cs.berkeley.edu/pubs/threads-hotos-2003.pdf> (The Capriccio project was really interesting too, on the paper. I do not know where they are now). Patrick Mézard
participants (6)
-
Alf P. Steinbach -
Boris -
Don G -
Jonathan Wakely -
Patrick Mézard -
Robert Ramey