A lock that times out but doesn't poll

Peter Hansen peter at engcorp.com
Mon Nov 29 04:39:35 CET 2004


Jive wrote:
> [OT]
> I don't draw any distinction between "soft" and "hard" realtime. 
 > I've never seen definitions for those terms that I thought were
 > useful.

The key difference is that one is a binary test, and the other
is not.  As an article writing by Steve Furr of QNX Software
says, "soft real time is a property of the timeliness of a
computation where the value diminishes according to its tardiness"
(but does not drop away completely to zero).

One simple way to look at it is that for a hard realtime system,
a given operation must complete 100% of the time within its
required time constraints or the system is defective, while for
a soft realtime system that value can be less than 100% and the
system is still considered functional.

I doubt any of this is new to you, but I thought I'd throw it
out there just in case.

>>One of the conditions for doing that should
>>probably be that the code is fairly widely used and widely
>>required.
> 
> Why?  If the existing code could be better, why not improve it?

I would guess the best answer to that is "how do we judge
that it's really better?"  And I think the answer to _that_
question is "by getting enough people who are very knowledgeable
in that area to exercise it enough to be able to form an
opinion about it, independent of its sole author." ;-)

>>Why not post it to an appropriate "recipe" page in the fledgling
>>Agile Control Forum site instead?  (http://www.engcorp.com/acf)
>>That way others who *do* work in the machine control field will
>>have an early chance to try out your code, experiment, maybe
>>even improve it, fix bugs,
> 
> Oh, there will be no bugs.

??  What kind of a statement is that?  I can think of only two
possibilities.  Either you are being deliberately provocative,
or you have such an extensive set of unit tests for it that
you feel confident making what would otherwise be a reckless
statement.  Or you are much less experienced than you sound.
_Three_ possibilities.  The three possibilities are ...

Seriously, why are you so confident about that?  Even if
the code were trivial, we're talking *threads* here...

-Peter



More information about the Python-list mailing list