Re: How to make sure my in-memory db does not flush corrupt page to disk?

On 8 Juli, 03:36, toby <t...@xxxxxxxxxxxxxxxxxxx> wrote:
On Jul 1, 10:43 pm, Sune <sune_ahlg...@xxxxxxxxxxx> wrote:



I have no idea what shmget, shmat, etc. are. What you need is code
to postpone access until after a previous access is complete.
await can examine the state of testlock, and if the unit is
available continue into the actual code. If not available, it has
to remain in await and retest. The retest should await the cycling
of the process scheduler.

You can avoid corrupt memory by simply using ECC memory. Advisable
in any case.

shmget and shmat etc are standard UNIX calls to allocate and attach to
shared memory. The shared memory block is loaded into the process
address space. By using shared memory I remove IPC overhead which
arises if I use a client/server connection between app/db

How can a piece of hardware detect if a pointer:

int* ptr;

points to the integer the app intends to, or points straight into an
integer in this shared memory block the app has loaded?

The more I think about this, a checksum scheme seams the only way to
go?

Isn't this a perfect use case for a separate process? That protects
your address space at the cost of IPC (instead of checksum). Are you
sure you can't afford this? Checksumming is a cost too.



Anybody out there who can confirm or shoot down this idea?

This sounds very reasonable. Thanks!

.

Relevant Pages