Re: Async I/O on IRIX 6.x?

On 12 Sep 98, at 16:52, Alex Rousskov <rousskov@nlanr.net> wrote:

> On Sat, 12 Sep 1998, Henrik Nordstrom wrote:
>
> > I don't regard malloc,free as MT-Safe. It may be on most platforms, but
> > certainly not all for a while yet.
>
> There are MT-Safe versions of them on IRIX, I think. Pthreads are certainly
> not portable to all problems anyway :)

 One must understand how MT-safe is achieved. Please note that there are 2
 distinct terms of interest: MT-Safe and MT-Async-Safe. First implies that
 calling MT-safe call is guaranteed to _not currupt_ lib's internal data,
 and MT-Async-Safe implies that OS is able (in addition) to process many
 concurrent calls in parallel. This is very important difference at times!

 If MT-safe is guaranteed by OS itself, then you have a chance that it may
 benefit from threading (if it is also Async-safe). By using 3rd-party
 threads library, for such library there is no way to provide concurrency
 easily, and most often MT-safe is achieved by enclosing entry point to
 the _whole_ library with a mutex.

 * This means that no 2 threads can be inside the same library at the same time.

 Unless you have MT-Async-Safe versions of any libs, either from 3rd party
 threads lib itself or provided by OS, using MT-safe-only calls in concurrent
 threads only asks for headaches.

 To illustrate: dnsservers are asking to be implemented as threads, right?
 I once tried that, and it worked fine. But, DNS times went skyrocket. Why?
 Because the whole resolv lib was protected by a mutex and all my threads
 where sitting on that mutex until getting a chance to enter the lib.
 Effectively all DNS queries were resolved serially, NOT in parallel.
 So, unless you write your own MT-Async-Safe resolver lib, there is no
 point in doing DNS queries in threads. Same goes for many libs. One must
 very carefully select which calls he uses from concurrent threads, because
 just one relatively slow async-Unsafe call might slow the whole process
 down considerably without any apparent reason.

 In this sense using OS provided threads should be highly preferred to
 other pthreads implementations, because to have parallelism OS has to
 run multiple concurrent kernel threads that do not interact badly, and
 to be efficient, pthreads and OS must be quite tightly coupled.

 Let me speculate: guess IRIX is able to process most IO calls
 concurrently, but close() is for some reason enclosed by a mutex.
 As close() is quite an expensive call, it takes time. And if open()
 and all other IO is running concurrently but close is done serially,
 you end up with close() threads stacking up...

 To come back to xmalloc, if you enclose library call with your own
 code, you take resposibility to provide MT-safeness. As Alex has found,
 there was a first bite. There may be more to come.

 Stew has designed ingenious async-io while avoiding mutexes. At a time
 we had quite a arguing about whether to write academic threaded code
 with zillions of mutexes or designing mutual exclusions algoritmically.
 He proved to be able to write a MT code without almost a single mutex,
 (and he deserves lots of beer for that) but it is way too easy to break.
 It is very difficult to follow and understand where it is safe to insert
 code and where there is a slightest possibility to brake mutual exclusion.
 Extreme care must be taken to use only sections of code that are MT-safe.

> > I even don't consider multiple IO functions on the same filedescriptor
> > as MT-safe on all OS:es if any (there is only one filepointer per
> > filedescriptor.. where does it point?).

 MT-Safe means only that it is guaranteed to not corrupt lib internal data.
 What you do with whats behind that is totally another issue. So, to be
 pedantic, we might say that on any OS that has ever heard of threads,
 multiple IO operations on the same FD is MT-Safe as each file should be
 protected by its own mutex, but doing multiple IO operation from concurrent
 threads is not safe for your goal, unless you know what you're doing. ;)

 ----------------------------------------------------------------------
  Andres Kroonmaa mail: andre@online.ee
  Network Manager
  Organization: MicroLink Online Tel: 6308 909
  Tallinn, Sakala 19 Pho: +372 6308 909
  Estonia, EE0001 http://www.online.ee Fax: +372 6308 901
 ----------------------------------------------------------------------
Received on Tue Jul 29 2003 - 13:15:54 MDT