I never knew this type of lock existed in pthread. I've used mutex quite a bit but my use-cases have been mostly single reader and single writer where mutex does basically the same job. This seems very useful if you have multiple readers though.
As mentioned at the end, reader locks do incur a performance overhead over mutex locks. Even if your critical section is only reading the locked variables, you may be better off just using a mutex lock. Usually you need to have a lot of readers with rather long critical sections for rwlocks to perform better than mutex locks.
There is also the issue of holding a reader lock and wanting to upgrade to a writer lock without releasing the reader lock (thereby allowing another writer to sneak in), which allows you to test-and-set all while holding the lock. It’s tricky though, because it’s prone to deadlock.
Sometimes it's useful to think of these as exclusive/shared locks. Normally you would write under an exclusive lock but read under a shared lock, but that's not always the case. For example, if you already have a thread safe object, you may want to write to it under a shared lock, but to read a consistent view of the object you would use an exclusive lock.
They also called exclusive lock for write and shared lock for read. Readers block creation of writer lock, but do not block creation of other reader locks. Writer lock blocks creation of all new locks. This thing also exist for files on file system, but their description and behavior is kinda crazy unfortunatly, so no easy to follow standards there.
It's interesting and kind of sketchy at the same time to cast a long to a void* and back. I would have allocated a count variable on the heap and passed that.
I'm kind of curious why you're not also showing the standard way to handle threads. I know that you know they added threading in C11, so why not do a video showing how to handle the same thing using the standard library? The interesting thing is, on the Linux system I'm using, the standard functions and types are just aliases for pthreads and I have to tell the linker to link the pthreads library to get standard threads to work. I'm sure MS and Apple both use their own facilities for threading, but I don't use either so you'd have to look for me.
That casting in 2:50 and 4:30 hurts my ocd. :-) You could have at least used uintptr_t instead of long. Casting long to void* and back again isn't very portable or is it?
This is an awesome video. Fantastic presentation of the material!
I never knew this type of lock existed in pthread. I've used mutex quite a bit but my use-cases have been mostly single reader and single writer where mutex does basically the same job. This seems very useful if you have multiple readers though.
The correct term is readers-writer lock (there can be many readers at once, but only one writer at once). It's called shared_mutex in C++.
As mentioned at the end, reader locks do incur a performance overhead over mutex locks. Even if your critical section is only reading the locked variables, you may be better off just using a mutex lock. Usually you need to have a lot of readers with rather long critical sections for rwlocks to perform better than mutex locks.
Great video! Could you make one where you cover synchronization based on compare and swap intrinsic?
yeah, that's probably doable. I'll add it to the list. thanks
There is also the issue of holding a reader lock and wanting to upgrade to a writer lock without releasing the reader lock (thereby allowing another writer to sneak in), which allows you to test-and-set all while holding the lock. It’s tricky though, because it’s prone to deadlock.
Sometimes it's useful to think of these as exclusive/shared locks. Normally you would write under an exclusive lock but read under a shared lock, but that's not always the case. For example, if you already have a thread safe object, you may want to write to it under a shared lock, but to read a consistent view of the object you would use an exclusive lock.
They also called exclusive lock for write and shared lock for read. Readers block creation of writer lock, but do not block creation of other reader locks. Writer lock blocks creation of all new locks.
This thing also exist for files on file system, but their description and behavior is kinda crazy unfortunatly, so no easy to follow standards there.
It's interesting and kind of sketchy at the same time to cast a long to a void* and back. I would have allocated a count variable on the heap and passed that.
I'm kind of curious why you're not also showing the standard way to handle threads. I know that you know they added threading in C11, so why not do a video showing how to handle the same thing using the standard library? The interesting thing is, on the Linux system I'm using, the standard functions and types are just aliases for pthreads and I have to tell the linker to link the pthreads library to get standard threads to work. I'm sure MS and Apple both use their own facilities for threading, but I don't use either so you'd have to look for me.
how to understand c code from decompilers like binary ninja ?
ANALYZE EVERY SINGLE BIT
That casting in 2:50 and 4:30 hurts my ocd. :-) You could have at least used uintptr_t instead of long. Casting long to void* and back again isn't very portable or is it?
What your are asking is how to understand assambly code.
Well… you understand it by studying about it 🤷
y r u not usin Rust? u is usin C in 2024? dat's tranzfobic r u a Trump voter too?
HAHA in Russia no adds in youtube :)