Making variables atomic in C

preview_player
Показать описание
---
Making variables atomic in C // we're talking about threads, thread safety, and atomicity, and specifically this video talks about the atomic keyword, added in C11 that allows you to make variables atomic without using locks.

Related Videos:

***

Welcome! I post videos that help you learn to program and become a more confident software developer. I cover beginner-to-advanced systems topics ranging from network programming, threads, processes, operating systems, embedded systems and others. My goal is to help you get under-the-hood and better understand how computers work and how you can use them to become stronger students and more capable professional developers.

About me: I'm a computer scientist, electrical engineer, researcher, and teacher. I specialize in embedded systems, mobile computing, sensor networks, and the Internet of Things. I teach systems and networking courses at Clemson University, where I also lead the PERSIST research lab.

More about me and what I do:

To Support the Channel:
+ like, subscribe, spread the word

Рекомендации по теме
Комментарии
Автор

Not covered: memory order acquire, release, relaxed, seq_cst. This can help performance a lot. By default, compiler chooses the safest but slowest implementation of atomic variable. However many places where counters are used no memory ordering is necessary so we are losing a performance here.

TheNovakon
Автор

Great video!

One related subject that might be nice to cover is the use of `__atomic_*()` GCC builtins, and how they differ from `_Atomic`.

Thanks for all the great content!

krobarr
Автор

as far as i remember locks use atomic vars for the lock itself, the reason why is faster is that locks come with a lot of additional logic compared to a atomic var.

olteanumihai
Автор

It's great that they're adding new features, but I feel like for most people this is going to be too little, too late. I would suggest though, instead of printing an error, having the locking code be a fallback. And it's sad if clang doesn't convert var = var + i into var += i because gcc does, even at -O0, and I'm still using the 10.3 version. Although, with higher optimization levels writing a minimum testable example is really annoying.

anon_y_mousse
Автор

We want more concurrency videos especially for embedded systems. Thanks for all the amazing videos.

semimaths
Автор

Hi, love your videos!
I was wondering if you can also do videos regarding Distributed Systems with C (MapReduce, scheduling, Sharding, etc.)

HatakeKakashii
Автор

While only getting this in C11 is a bit late, I still love the idea of having an atomic keyword. Signaling to the compiler that variable r/w should occur atomically opens up way more oportunities than just using a lock yourself. Most platforms support atomic instructions, where as the compiler could never adapt them if you're locking explicitely. And if they don't, it's easy to auto-generate the lock.

blvckbytes
Автор

It's good to know how to use threads and mutexes appropriately, but I think what would make for a good video would be the major differences between a
mutexes and semaphores. When I was starting to learn Vulkan, I came across the usage of semaphores as opposed to mutexes, although mutexes could still be used throughout the usage of the API. If I remember correctly Vulkan allows you to write your own custom memory manager, however when working with their thread pool, they have built in semaphores. I know I learned about the two long ago, but it would be a great refresher to hear you explain the difference between the two.

skilz
Автор

At 10:09, you list `a /= b` and `a *= b` as atomic operations. I can't find any reference for C11 implementing these compound assignments atomically. I know that C++11 certainly doesn't, so I would be suprised if C11 does. Generally, when I need such atomic ops I'd implement them manually using `compare_exchange_weak` loops.

Skeksis
Автор

_Atomic does not tell the compiler that you want access to the variable to be atomic, it only tells the compiler to make sure it chooses a type that can be updated atomically. That "+=" works in your code is coincident, as the standard does not guarantee that to be the case.

See ISO/IEC 9899:201x, §7.17.7.5, Section 5:

"The operation of the atomic_fetch and modify generic functions are nearly equivalent to the operation of the corresponding op= compound assignment operators. The only differences are that the compound assignment operators are not guaranteed to operate atomically, and the value yielded by a compound assignment operator is the updated value of the object, whereas the value returned by the atomic_fetch and modify generic functions is the previous value of the atomic object."

Note the "are not guaranteed to operate atomically". The standard does not guarantee that your code is atomic, it only is because on your system native 64 bit atomics seem to exist. The correct code that is guaranteed to always be atomic would have been:

atomic_fetch_add(&counter, i);

xcoder
Автор

Wow. This detailed description... keep on.

damn_right_man
Автор

One minor part :
Why is count_to_big incrementing by i and not one ?

If incremented by one, we can assert that counter is equal to 2*BIG

dudeabideth
Автор

You could always use atomic and fallback to lock yourself if not supported.
also maybe mention the stdatomic functions and varible?

mrcrackerist
Автор

Thanks for a great video! @around 6:00 Is it possible to implement a lock() function if the hardware does not support something like compare/swap? Also, have you done a video on linker scripts? Would be really interesting :-) Thanks & I wish you a fantastic summer.

benarcher
Автор

Atomic is wonderful, related topics: memory models, thread_sanitizer, false sharing, core ping-poing and more over to go deeper =)

end-ikend-ik
Автор

Can you also cover memory order, memory fenses?

mshingote
Автор

A better word for”Mutex” is “Bottleneck”!

ChrisAthanas
Автор

made me think of how often it would be easy enough to simply compile and test/compare both versions of some code. generally, when is comparing two or more variants of code trivial and straightforward, and when is it not practical and too much effort? would be great to hear from experienced people what to consider re this

peppigue
Автор

But what about memory ordering? Which semantics does C use?
In C++ you can/have to specify the memory ordering for atomic operations.

embeddedbastler
Автор

Maybe some day we will see a video about GCC extensions for C. They are very, very interesting.

rogo