Markus.Kuhn at cl.cam.ac.uk
Sun Oct 4 09:42:23 UTC 1998
Antoine Leca wrote on 1998-10-02 13:27 UTC:
> My real concern is that lazy implementers (there are a lot of
> them) may, and probably will, implement it as a busy wait
> on some platforms, while other resources may be perhaps
> available, but probably more difficult to use.
> That is what I did not like.
> Also, I do not like the sad effect: if xtime_delay *could* be
> implemented as a busy wait, there will be some programmers
> that will refuse to use it for effiency reasons (look at
> the people that rewrite memmove because some implementers
> wrote it using malloc... thus avoiding the speedy block
> moves implemented by others :-( ).
> But you are right that a "delay" statement (in one way or
> another) is a practical quest for a fair number of people.
I have been following issues related to international standardization
for around a decade now. One of the important things that I have learned
is that IT standards are not a suitable instrument for ensuring the
quality of software products. Standards (if very carefully written) are
a reasonable good aid (but not a guarantee!) in helping implementors to
create portable products. The quality of a software product depends
exclusively on the skills and motivation of the implementor, and no
possible standard can ensure a high quality implementation (except if
you specify the entire product byte-by-byte, which is equivalent to
making is available freely -> the Olson library). We have other
mechanisms to ensure quality, namely the market and user feedback.
Standards help to create a fair market, because they allow you to build
your infrastructure independent of individual suppliers. This gives you
as the customer the opportunity to avoid the lazy implementor and chose
the most competent one. So please let's not get into discussions about
what lazy implementors might do with a specification. Trust me: if you
do use products from a lazy implementor, you will have problems anyway,
no matter what you write in the standard.
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>
More information about the tz