cnd has asked for the wisdom of the Perl Monks concerning the following question:

I notice there's no locking or atomic operations possible, right?

e.g. even a $database_key++ operation is going to give the wrong answer if 2 processes do that at the same time. Yes - I tested this. we get 2 FETCH, both before 2 STORE, clobbering data (no matter what mechanism is under-the-hood).

Which makes me wonder - how do folks deal with using tie on multiprocess/multithread projects?

Replies are listed 'Best First'.
Re: atomic tie?
by ikegami (Patriarch) on Aug 11, 2024 at 14:59 UTC

    It's not atomic without tie either.

    Locks.

[reply]
Re: atomic tie?
by talexb (Chancellor) on Aug 12, 2024 at 15:55 UTC

    You're implying that this might be a problem with a database key, but I suspect you're wrong -- because that's one of the problems that databases were specifically designed to solve. For example, if you do something inside a database transaction that involves incrementing a counter and then using it, there should never be a problem.

    Give us a concrete example of what you're talking about (maybe to do with threads?), and we'll have a better idea of how to respond.

    Alex / talexb / Toronto

    Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

[reply]

      if you do something inside a database transaction

      To paraphrase a lesson i had to give a coworker a couple of years ago: "If you ever do something outside of a proper transaction in one of my database systems *again*, you will get your keyboard permanently revoked so fast that it will leave burn marks on your fingertips"...

      PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
      Also check out my sisters artwork and my weekly webcomics
[reply]
        Not all DB engines support transactions, and those who pretend they do show sometimes weird side effects.

        (Yes MySQL)

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        see Wikisyntax for the Monastery

[reply]
Re: atomic tie?
by LanX (Saint) on Aug 11, 2024 at 17:04 UTC
    In Which Context?
    • Database?
    • Multi threading?
    • Forking?

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    see Wikisyntax for the Monastery

[reply]
Re: atomic tie?
by Anonymous Monk on Aug 11, 2024 at 14:21 UTC
    under-the-hood

    under the hood of what?

[reply]
Re: atomic tie?
by perlfan (Parson) on Aug 24, 2024 at 01:09 UTC
    perl is a serial process. If your getting a race condition, it's between 2 or more forked perl processes; which leads to another issue of forking and database handles; this can be very dangerous - particularly when it comes to SQLite. Also, you incrementing a key also in that environment is also very risky. If you want to avoid collisions and not change your set up, you need to look at generating some kind of globally unique identifier or checksum of the data record you're adding. You need to let the esteemed monks know what you're doing.
[reply]
[d/l]
[select]

      perl is a serial process.

      Have you not heard of threads, coros and signal handlers? (There are surely others.)

[reply]
        Yes, but perl itself is fundamentally a single process. All that other stuff is to avoid the inherent lack of thread safety. I understand it was never meant to be thread safe, so don't take that as a criticism.
[reply]
[d/l]

Back to Seekers of Perl Wisdom