|
Size: 2521
Comment: remove content
|
Size: 1992
Comment: update content - w/ Sam
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 7: | Line 7: |
| = Atomic Operations for 32 and 64 Bit Values = | = Atomic Operations = |
| Line 15: | Line 15: |
| This category contains functions for handling atomic operations in both 32-bit and 64-bit platforms. <<Color2(green,Seems like this is still valid.)>> At the very minimum spin locks must be implemented. Without spin locks it is not possible (AFAICT) to emulate the rest of the atomic operations. <<Color2(green,Should this be moved to the end?)>> <<Color2(green,This section is the new intro text after the header revisions.)>> |
This category contains functions for handling atomic operations. |
| Line 37: | Line 33: |
| These operations may or may not actually be implemented using processor specific atomic operations. When possible they are implemented as true processor specific atomic operations. When that is not possible the are implemented using locks that *do* use the available atomic operations. <<Color2(green,Should *do* be bold or italics instead?)>> | These operations may or may not actually be implemented using processor specific atomic operations. When possible they are implemented as true processor specific atomic operations. When that is not possible the are implemented using locks that '''do''' use the available atomic operations. |
| Line 40: | Line 36: |
<<Color2(green,Does the comment in the header about intrin.h belong here?)>> |
DRAFT |
Atomic Operations
Include File(s): SDL_atomic.h
Introduction
This category contains functions for handling atomic operations.
![/!\](/moin_static198/fixedleft/img/alert.png "/!\"){kind=small}
IMPORTANT:
- If you are not an expert in concurrent lockless programming, you should only be using the atomic lock and reference counting functions in this file. In all other cases you should be protecting your data structures with full mutexes.
The list of "safe" functions to use are:
Seriously, here be dragons!
You can find out a little more about lockless programming and the subtle issues that can arise here:
There's also lots of good information here:
These operations may or may not actually be implemented using processor specific atomic operations. When possible they are implemented as true processor specific atomic operations. When that is not possible the are implemented using locks that do use the available atomic operations.
All of the atomic operations that modify memory are full memory barriers.
Atomic Locks
The atomic locks are efficient spinlocks using CPU instructions, but are vulnerable to starvation and can spin forever if a thread holding a lock has been terminated. For this reason you should minimize the code executed inside an atomic lock and never do expensive things like API or system calls while holding them.
The atomic locks are not safe to lock recursively.
