in reply to Re^5: Multiple write locking for BerkeleyDB
in thread Multiple write locking for BerkeleyDB

It really isn't any more complex, it's just that DBI and mysql wrap most of that up for you.

That's an odd definition of complexity you've got there. What would you think of the equivalent solution in assembler? Or constructed using syscall() instead of the shm*() routines? Obviously these would do the same work for you, it's just that GCC "wraps most of that up for you."

It's interesting to see that SysV semaphores perform pretty well. It doesn't match my experience with SysV shared memory, which was about as slow as just using disk, but I guess that's apples and oranges. And let's not even talk about the arbitrary kernel-level limits on this stuff (how many, how much storage, etc).... It might work great on Linux, but porting to BSD or Solaris where the defaults are much different is a guaranteed pain.


  • Comment on Re^6: Multiple write locking for BerkeleyDB

Replies are listed 'Best First'.
Re^7: Multiple write locking for BerkeleyDB
by sgifford (Prior) on Apr 24, 2008 at 16:50 UTC
    Since the OPs question was about performance, I was talking about computational complexity, the amount of work that the computer has to do. Obviously SysV is more complex to code.

    As far as SysV semaphores and shared memory, it's not that they are particularly fast, they're just faster than performing many very small transactions with a database. It may well be that performance is the same as using a small disk file, which should also be pretty fast, as long as the OS is smart about caching and delayed writes. Look at mmap in my updated benchmarks to see fast. :-)

    Not sure about portability. I'm using all modules that come with Perl and using only the most basic features, so I would expect it to be at least portable across Unix-like systems. Apart from flock I don't know of another native perl mechanism to do an interprocess mutex.