I expect that is more or less what will happen. Still, those parts of the code that relies on random numbers will have to be identified and tested, so it will need some time even if existing number generator code is used.

/Rolf 

When creating file names to pass to a policy (data file ~X, result file ~R and sentinel file ~S), Mercury (v. 4.72) seems to reuse file names rather than generating random names for each invocation of the policy. This causes a race condition that has bitten me a couple of times: the data file for a second invocation of the policy is given the same name as the result file of a first invocation. As a consequence, the first invocation generates a false exception (non-empty result file) and its result file is the actual data (CNM file) of the second invocation.

To verify this, I modified my policy so that it would also log the date, time and name of the ~X ~R and ~S files passed to it. Here's a small piece of that log:

  DATE     TIME       ~X                   ~R                   ~S

03/01/11 20:21:30 c:\mtmp\LKVD2AYJ.TMP c:\mtmp\KYKVVWGR.TMP c:\mtmp\154BLXEM.TMP
03/01/11 20:21:51 c:\mtmp\KYKVVWGR.TMP c:\mtmp\SAAANORJ.TMP c:\mtmp\1XX95QL9.TMP
03/01/11 20:22:11 c:\mtmp\LKVD2AYJ.TMP c:\mtmp\KYKVVWGR.TMP c:\mtmp\154BLXEM.TMP
03/01/11 20:22:43 c:\mtmp\W0IAKS6M.TMP c:\mtmp\154BLXEM.TMP c:\mtmp\LKVD2AYJ.TMP
03/01/11 20:22:43 c:\mtmp\W0IAKS6M.TMP c:\mtmp\154BLXEM.TMP c:\mtmp\LKVD2AYJ.TMP
03/01/11 20:22:44 c:\mtmp\W0IAKS6M.TMP c:\mtmp\154BLXEM.TMP c:\mtmp\LKVD2AYJ.TMP
03/01/11 20:33:00 c:\mtmp\LKVD2AYJ.TMP c:\mtmp\KYKVVWGR.TMP c:\mtmp\154BLXEM.TMP
03/01/11 20:33:32 c:\mtmp\W0IAKS6M.TMP c:\mtmp\154BLXEM.TMP c:\mtmp\LKVD2AYJ.TMP
03/01/11 20:39:58 c:\mtmp\LKVD2AYJ.TMP c:\mtmp\KYKVVWGR.TMP c:\mtmp\154BLXEM.TMP
03/01/11 20:40:31 c:\mtmp\W0IAKS6M.TMP c:\mtmp\154BLXEM.TMP c:\mtmp\LKVD2AYJ.TMP
03/01/11 20:43:05 c:\mtmp\LKVD2AYJ.TMP c:\mtmp\KYKVVWGR.TMP c:\mtmp\154BLXEM.TMP

Just think about what would happen if the first invocation had not finished by the time the second invocation was called. The log for the whole day only has 6 or 7 different file names.

Thomas and I passed this matter on to the beta tester list. David has now investigated it and after a lot of digging he found the culprit. The function in the Borland runtime library that generates random numbers has an undocumented threading problem. If a program, such as Mercury, fires multiple threads, each thread will produce identical sequences of "random" numbers.

This is a really big issue that affects more than policy filenames, and all code using this function has to be modified. This will be done in Mercury 4.73 that was due to be released any day but now will need some more time to complete and test.

Thanks for pointing it out and sharing the log data! 

/Rolf 

I hate to be second-guessed myself, but rather than modifying all the code that uses the faulty random number generator, wouldn't it be easier to just write a replacement random number generator that uses the same API as the faulty one? There are some very good random number generators with source code in the public domain.