Exposing RawMutex and RawRwLock in the public API? about parking_lot HOT 11 CLOSED

No, this is still not possible and will never be possible. You should use an OS-specific mutex that supports this.

from parking_lot.

I personally just use Mutex<()> when I need a raw mutex for low-level code. Is this insufficient in your case?

from parking_lot.

I did think of that, but was unsure what the following code would then compile down to:

pub struct RwLock<T: ?Sized> {
    raw: RawRwLock,
    data: UnsafeCell<T>,
}

What does rustc do with data? My guess is that it stops existing entirely, but I don't really want to rely on that for raw memory I'll be mmap()ing to disk.

Which leads me to another question: RawRwLock uses an AtomicUsize internally, which means that the size of the struct varies on 32 vs 64 bit OSs. Since I want to use RawRwLock in a B-tree page that is going to be written to disk through mmap(), I need a stable size. I could write some metadata to the file to detect if someone tries to read on a 32 bit OS a file written with on 64 bit OS, but that's a hassle I'd rather avoid.

If this were all in-memory, then Mutex<()> would suffice, but since I'm writing to disk, having a known size makes life much easier.

Could RawRwLock use an AtomicU32?

from parking_lot.

data does get completely optimized anyways, however RawRwLock uses AtomicUsize internally, so this won't help in your case.

Another issue is that parking_lot mutexes and rwlocks are not consistent across processes, such as if two processes mmap the same file and both try to grab the same lock, you will have issues.

For your use case I would strongly recommend using Linux futexes directly, which are always based on an AtomicU32. If you do not use FUTEX_PRIVATE_FLAG then futexes will work correctly across multiple processes.

from parking_lot.

Another issue is that parking_lot mutexes and rwlocks are not consistent across processes, such as if two processes mmap the same file and both try to grab the same lock, you will have issues.

For your use case I would strongly recommend using Linux futexes directly, which are always based on an AtomicU32. If you do not use FUTEX_PRIVATE_FLAG then futexes will work correctly across multiple processes.

This I agree is excellent advice, but I don't need the ability to read this on-disk data from multiple processes at the same time (and won't be able to for other architectural reasons). I'm using mmap() for fast access to a multi-GB file that's possibly beyond the size of RAM.

I don't actually need the RawRwLock to be persisted to disk at all. I'm putting it in the B-tree page for the sake of performance (data locality).

from parking_lot.

In that case you could just reserve space for a 64-bit value in your file format, but only use the low 32 bits if you are running on a 32-bit OS.

from parking_lot.

And add assert!(mem::size_of::<RwLock<()>>() <= 8) to catch any (unlikely) changes to the size of RwLock.

from parking_lot.

That's actually a pretty good idea! Didn't think of that at all; seems obvious in retrospect.

8 bytes is can be quite a lot for low-level code; what benefits do you see in keeping it usize vs fixing it to u32?

from parking_lot.

Mainly because AtomicU32 isn't stable yet, while AtomicUsize is. Also because in theory, the maximum number of concurrent read locks is proportional to the address space size (hence usize).

from parking_lot.

Mainly because AtomicU32 isn't stable yet, while AtomicUsize is.

That's a pretty good reason; I was unaware that AtomicU32 was unstable.

Also because in theory, the maximum number of concurrent read locks is proportional to the address space size (hence usize).

Technically true, but I'd add that any system even remotely approaching 2^32 concurrent read locks has already failed quite a while ago. :D

You've answered all my questions, thanks a ton!

from parking_lot.

@Amanieu You say that parking_lot mutexes and rwlocks cannot be used across process boundaries, is this still true?
( I am not sure why it would have changed, but you did mention using mmap in #305, so it seems, that it could be possible)

from parking_lot.