> The thing about well-intentioned but incorrect locking code is that
> it will appear to work fine, until it trips over the one code path
> where it forgets to lock some file that it should have locked. And
> even then, the code will "work" just fine, until multiple processes
> are accessing that file at the same time.
Which is why you perform unit testing, itegration testing, and full
branch path validation, if you are a professional software engineer
engaging in due dilligence.
Unfortunately, most professional software engineers are only
permitted by their management to engage in due dilligence when the
softwar being worked on is part of a life-support system of some
kind (e.g. the software that runs on the microcontroller in your
cars anti-lock braking system).
Most software malfunctions are the result of either software
engineer unprofessionalism or management unprofessionalism,
not because "software is magic" and not because "software is
this amorphorous thing" and not because "the software is too
complex for one mind to grasp all of it".
Anyone who tells you any different is either lying or a hardware
engineer.
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
