Setting a bit
Use the bitwise OR operator (|
) to set a bit.
number |= 1UL << n;
That will set the n
th bit of number
. n
should be zero, if you want to set the 1
st bit and so on upto n-1
, if you want to set the n
th bit.
Use 1ULL
if number
is wider than unsigned long
; promotion of 1UL << n
doesn't happen until after evaluating 1UL << n
where it's undefined behaviour to shift by more than the width of a long
. The same applies to all the rest of the examples.
Clearing a bit
Use the bitwise AND operator (&
) to clear a bit.
number &= ~(1UL << n);
That will clear the n
th bit of number
. You must invert the bit string with the bitwise NOT operator (~
), then AND it.
Toggling a bit
The XOR operator (^
) can be used to toggle a bit.
number ^= 1UL << n;
That will toggle the n
th bit of number
.
Checking a bit
You didn't ask for this, but I might as well add it.
To check a bit, shift the number n to the right, then bitwise AND it:
bit = (number >> n) & 1U;
That will put the value of the n
th bit of number
into the variable bit
.
Changing the nth bit to x
Setting the n
th bit to either 1
or 0
can be achieved with the following on a 2's complement C++ implementation:
number ^= (-x ^ number) & (1UL << n);
Bit n
will be set if x
is 1
, and cleared if x
is 0
. If x
has some other value, you get garbage. x = !!x
will booleanize it to 0 or 1.
To make this independent of 2's complement negation behaviour (where -1
has all bits set, unlike on a 1's complement or sign/magnitude C++ implementation), use unsigned negation.
number ^= (-(unsigned long)x ^ number) & (1UL << n);
or
unsigned long newbit = !!x; // Also booleanize to force 0 or 1
number ^= (-newbit ^ number) & (1UL << n);
It's generally a good idea to use unsigned types for portable bit manipulation.
or
number = (number & ~(1UL << n)) | (x << n);
(number & ~(1UL << n))
will clear the n
th bit and (x << n)
will set the n
th bit to x
.
It's also generally a good idea to not to copy/paste code in general and so many people use preprocessor macros (like the community wiki answer further down) or some sort of encapsulation.
Best Answer
Cross-process semaphores are an operating system specific operation.
What most of these share is that you create the semaphore in one process via a virtual path which dubs as the semaphore's name. If permissions are correctly set, you can the open the semaphore in another process by using the same virtual path. These virtual paths aren't usually real filesystem paths even if they look familiar.
On POSIX/System V-based systems, you typically have two options. The differences between the two options are very well explained in this answer.
System V semaphores
These are path-based semaphores that can be obtained with
semget()
:Note that it is important to cleanup the semaphores, as System V semaphores stay around until explicitly unlinked. Which is kind of a problem when a process crashes without cleaning up its semaphores (e.g. FreeBSD comes with a utility
ipcrm
do remove dangling System V IPC objects).POSIX Semaphores
These are actually less widely implemented, so check if your kernel supports them. The named version of these is are obtained via
sem_open()
.POSIX semaphores are implicitly destroyed when the last process having a handle to the semaphore exits. They are rumored to be faster than System V semaphores
Windows
Windows has its own semaphore APIs: Semaphores are created by
CreateSemaphore()
.Windows uses the same naming trick as POSIX but with different namespace conventions.
Don't forget to add error checking when adapting the examples above. Also note that I have deliberately ignored permissions to simplify the code. Don't forget to add the relevant flags.
In addition to all this you can also (as commonly done before the arrival of real semaphores) abuse file locks as a form of binary mutex.