91–100 of 137 posts
Earlier quoted context omitted.
Sounds good, what is your solution and why didn't you explain it in your first reply?
What is my solution to what? To database I/O? I guess that's what the article is about...
You said "There is no need for file-backed memory to do that."
If that is true, I want to know what you are talking about, so I'm just asking you to back up the claim you made.
Earlier quoted context omitted.
They said you get a data race if you use read() and write() without file locks. You asked "Are you saying that without mmap() there will be data races??". No, they are saying you get a data race if you use read() and write() without file locks.
> No, they are saying you get a data race if you use read() and write() without file locks. Since you seem to understand better and my questions never made sense, maybe you can explain now why would we do that?
They said something that I thought was clear: you need file locks with read() and write().
I think you misunderstood that to mean only mmap can avoid data races.
What they actually said was that using mmap allows atomics so you can avoid file locks.
Earlier quoted context omitted.
What is my solution to what? To database I/O? I guess that's what the article is about...
I said "lock free memory based interprocess communication" You said "There is no need for file-backed memory to do that." If that is true, I want to know what you are talking about, so I'm just asking you to back up the claim you made.
You can do "lock-free memory based interprocess communication" with memory (obviously). There is no need to back this memory with files, certainly not files on a hard drive that you would otherwise access using read() and write(). Hence my original question.
Earlier quoted context omitted.
I said "lock free memory based interprocess communication" You said "There is no need for file-backed memory to do that." If that is true, I want to know what you are talking about, so I'm just asking you to back up the claim you made.
No. _I_ want to know what we're talking about, as my original question clearly indicates. You can do "lock-free memory based interprocess communication" with memory (obviously). There is no need to back this memory with files, certainly not files on a hard drive that you would otherwise access using read() and write(). Hence my original question.
lock free memory based interprocess communication (copied from my first reply)
There is no need to back this memory with files
Again, I'm interested in how you have two processes read and write lock free directly to the same memory if you don't use a memory mapped file.
You have said it isn't necessary, I'm just asking you to back up this claim and explain exactly what you mean.
Earlier quoted context omitted.
No. _I_ want to know what we're talking about, as my original question clearly indicates. You can do "lock-free memory based interprocess communication" with memory (obviously). There is no need to back this memory with files, certainly not files on a hard drive that you would otherwise access using read() and write(). Hence my original question.
_I_ want to know what we're talking about lock free memory based interprocess communication (copied from my first reply) There is no need to back this memory with files Again, I'm interested in how you have two processes read and write lock free directly to the same memory if you don't use a memory mapped file. You have said it isn't necessary, I'm just asking you to back up this claim and explain exactly what you me…
Also, you can use normal (non-file-backed) memory to do the necessary synchronization (lock-free or not). I'm still not seeing why the memory should be backed by a file, that's why I was genuinely asking. One reason why it could be practical that I can now see could be for an embedded database like sqlite, but again I'm not sure it would be a good idea. While it would allow for pretty much setup-less synchronization of otherwise uncoordinated processes, it's a fringe application that might be better implemented with one big flock(). And one reason why it could be not a good idea is that it might couple the file format to a particular CPU architecture.
Another big issue I guess is that the atomics actually do have an effect to the underlying file whenever the pages are flushed. What if the computer shuts down unexpectedly? The synchronization affairs aren't cleaned up, yet the original processes are gone.
Earlier quoted context omitted.
> No, they are saying you get a data race if you use read() and write() without file locks. Since you seem to understand better and my questions never made sense, maybe you can explain now why would we do that?
This is just goal post shifting. They said something that I thought was clear: you need file locks with read() and write(). I think you misunderstood that to mean only mmap can avoid data races. What they actually said was that using mmap allows atomics so you can avoid file locks.
You need _synchronization_. Not necessarily one of mmap() or file locks.
Earlier quoted context omitted.
I'm the author (well, one of) RavenDB You are correct to an extent, but there are a few things yo noted. * you can design your system so the access pattern that the OS is optimized for matches your needs * you can use madvise() to give some useful hints * the amount of complexity you don't have to deal with is staggering
The mongodb developers once thought as you did. They were wrong, although it took a fair while for them to realise this. Yes it's complex. Extremely complex, and as another poster noted, the learning curve is horrible and documentation is extremely limited. Unfortunately there's no real substitute. The mmap/madvise approach works well for things like varnish cache, where you have a flat collection of similar and larg…
Earlier quoted context omitted.
_I_ want to know what we're talking about lock free memory based interprocess communication (copied from my first reply) There is no need to back this memory with files Again, I'm interested in how you have two processes read and write lock free directly to the same memory if you don't use a memory mapped file. You have said it isn't necessary, I'm just asking you to back up this claim and explain exactly what you me…
First, I didn't assume it a requirement to have two processes read() and write() _directly_ to the same memory (I suppose you meant "file region" here). And idk, it might not be a good idea to require that. Also, you can use normal (non-file-backed) memory to do the necessary synchronization (lock-free or not). I'm still not seeing why the memory should be backed by a file, that's why I was genuinely asking. One reas…
You weren't asking, you were saying it wasn't necessary, which you did in the sentence right before this one:
Also, you can use normal (non-file-backed) memory to do the necessary synchronization (lock-free or not).
Again, this is just a repeated claim, it isn't an explanation. How do you have two processes writing to the same place in memory without memory mapping a file?
have two processes read() and write() _directly_ to the same memory
I didn't say read() and write() I said read and write as in reading and writing with memory addresses. Again, this is all about lock free interprocess communication. You can't write outside your own memory from a process with normal permissions so how do you share memory with another process?
You memory map the same file. This isn't about the file being written to some sort of persistent storage, that happens on the OS level and doesn't interfere with two running processes communicating with each other. The file can be deleted after the last process closes it. It is just a way for the two processes to have memory mapped into their virtual memory space that overlaps with each other.
You need to deal with memory directly so you can use atomics. You need to use atomics so you can avoid locks.
I thought you might have had some other technique that I'm not aware of but it seems now you were making claims without much behind them, which is disappointing.
The pragmatic consideration that usually influences the decision to use mmap() is the large discontinuity in skill and expertise required to replace it. Writing your own alternative to mmap() can be significantly superior in terms of performance and functionality, and often lends itself to a cleaner database architecture. However, this presumes a sufficiently sophisticated design for an mmap() replacement. The learni…
The original version of MongoDB used mmap, and I worked at a company that had a ton of issues with cache warmup and the cache getting trashed by competing processes. Granted this was a long time ago, but the main issue was the operating system's willingness to reallocate large swaths of memory from the address space to whatever process was asking for memory right now. Once the working set got trashed, performance wou…
mmap access patterns seem like something where you can do better. Especially in the age of io_uring, when an n+1 pointer chasing situation doesn't particularly care what order the results are processed as long as the last one shows up in a reasonable amount of time.
Earlier quoted context omitted.
This is just goal post shifting. They said something that I thought was clear: you need file locks with read() and write(). I think you misunderstood that to mean only mmap can avoid data races. What they actually said was that using mmap allows atomics so you can avoid file locks.
> They said something that I thought was clear: you need file locks with read() and write(). You need _synchronization_. Not necessarily one of mmap() or file locks.
This was never up for debate and is more diversion.
Was someone "saying you have to use mmap or you get data races??"
No, no one was saying that. You need it to do lock free synchronization because you need to map the same memory into two different processes to use atomics.
That's the whole thing.