Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^6: avoiding a race (place snark here)

by tye (Sage)
on Sep 29, 2010 at 20:53 UTC ( [id://862698] : note . print w/replies, xml ) Need Help??


in reply to Re^5: avoiding a race (the ado, you do, so well:)
in thread avoiding a race

And even in a full directory and an a loaded system, that time is going to be measured--assuming you can actually measure it at all--in low milliseconds at the most.

No, not at all. Opening the file requires finding the file which requires traversing the (possibly long) directory contents yet again (and thus contending with all of the mutex contention again also). With NTFS or a newer Linux file system (with the proper options enabled), then the directory won't be stored as a simple list and the performance is probably not as easily pathological. A few months ago I again ran into a directory with way too many files it in and it took many seconds, even minutes, to open a file (or to remove one). I haven't tried to replicate the problem on a more modern filesystem to see how well it scales. But I suspect there are plenty of file systems left in the world that were built without hash/tree directories.

And then only if the time-stamp resolution of the file-system is sufficient to actually discern the difference, which is unlikely.

And there you have your broken analysis, again. If X and Y fail to find 'file1' and then both create it, then the fact that the timestamp is not changed by whichever attempt is second has no bearing on the fact that both X and Y will then go on to send an e-mail. (Or, you can remove the race.)

- tye        

  • Comment on Re^6: avoiding a race (place snark here)

Replies are listed 'Best First'.
Re^7: avoiding a race (place snark here)
by BrowserUk (Patriarch) on Sep 29, 2010 at 21:17 UTC
    I again ran into a directory with way too many files it in

    So, don't put time-critical files in huge directories.

Re^7: avoiding a race (place snark here)
by BrowserUk (Patriarch) on Sep 29, 2010 at 21:10 UTC
    both X and Y will then go on to send an e-mail.

    No. They won't. Because the email isn't sent until an hour later.

    Are your eyes okay?


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Ah. A tiny change to the original specification leads to "notify of errors but never more than once per hour for the same error", which is something I've seen done many times and is an obvious enhancement for a notification system and how I interpreted it.

      Not notifying at all unless an error repeats after at least an hour is a strange specification but that is the original proposal as written. That also leaves an open question of what the window (if any) is for when you can purge ancient error messages (which is surely not just sensible but required for the system to not eventually just fall over).

      As written, the spec is also broken because (unless you add to it), once an hour has passed you get an e-mail for every single repeat of the same error (which is clearly not what is desired based on the justification given).

      And that still leaves a race with multiple e-mails, just a slightly different one. If X and Y both find 'file1' with a timestamp of more than 1 hour ago, then they will both e-mail about the same error at the same time. If you remove the race, then only the one that manages to update the timestamp of 'file1' would send the e-mail (for the next hour).

      And, no, I'm not convinced that my misreading of the original spec isn't actually what is really desired. (The original spec, as written, is clearly not what is really desired.)

      - tye        

        once an hour has passed you get an e-mail for every single repeat of the same error

        To quote my psuedo-code:

        a) If it is older than 1 hour: you delete the file; send an email; then move on

        As for whether the OP knows what he wants. Not my call. If he changes his spec, then I'd offer a different solution.

        I'd also probably close the miniscule window by using O_CREAT | O_EXCL, as discused way back there somewhere.