"Garrett D'Amore" <gdamore at sun.com> wrote:
> I think you and Wyllys are in violent agreement. :-) The original
> program has to be modified to use pthreads, rather than trying to hide
> this underneath a Pth wrapper. That means that you recompile the
> program, and possibly have to modify the source if it is not truly
> concurrent safe.
OK, I understand. I am a very defensive programmer ;-) I know that is is not
simple to find this kind of problems by just looking at the source, it if
appears to work.
Let me give an example:
Around 1988, I aded a "FIFO" to star based on shared memory. This code did
run fine for everybody for a really long time, even though there have been
multi-CPU Sparc systems since around 1992. A few weeks after I started to use
my first Dual Opteron system at home (in December 2005), star did expose hangs
after creating archives > 1 GB. This turned out to be a result of using
non-atomic instructions for synchronizing both processes that access the
shared memory. In 1988, I was just not aware of the problems caused by real
concurrency.
Two weeks after I fixed the problem, I received lots of mails from other people
that mentioned the same problem....
So even if you do not find any problem today, it may fail a few weeks later.
This is why would be very careful with introducing real concurrency in a Pth
replacement.
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
