Re: tmpnam() not unique

On Wed, Oct 15, 2014 at 10:15 AM, Bradley Stone <bvstone@xxxxxxxxx> wrote:

I quit using anything timestamp related for temp file names years ago when
collisions started happening. Not often, but they did.

Depending on the application, the timestamp (to the microsecond) can
still be a useful and easy way to generate *part of* a unique
identifier. I want to stress "depending on the application". (After
all, for some applications, just a simple date is already enough!)
And also to stress "part of". I would think there are plenty of
applications where timestamp combined with job info provides plenty of
uniqueness.

Now I just create a data area for my application and create a function to
get the next ID (ie, read in the data area value, lock it, add one to it,
then unlock it).

For maximum robustness and simplicity, shouldn't acquiring the lock
happen first, before even reading it? In other words, don't you have
to guard against

JobA - reads 39
JobB - reads 39
JobA - gets lock
JobA - sets value to 39+1
JobA - releases lock
JobB - gets lock
JobB - sets value to 39+1
JobB - releases lock

John Y.