Lock-Free, Thread-safe Monotonic Clocks
Lock-Free, Thread-safe Monotonic Clocks
Offset from Gregorian epoch (1582-10-15) in 100-nanosecond intervals. This constant is used to shift time values to the Gregorian calendar base used in UUID v1 and v6 timestamps.
Offset from Gregorian epoch (1582-10-15) in 100-nanosecond intervals. This constant is used to shift time values to the Gregorian calendar base used in UUID v1 and v6 timestamps.
Offset for converting from Gregorian epoch timestamps to Unix epoch timestamps. Used in posix-time calculations to shift time base from 1582 to 1970.
Offset for converting from Gregorian epoch timestamps to Unix epoch timestamps. Used in posix-time calculations to shift time base from 1582 to 1970.
(monotonic-time)Generate a guaranteed monotonically increasing timestamp.
Returns a 60-bit timestamp in 100-nanosecond intervals since the Gregorian epoch (1582-10-15), used by UUID v1 and v6.
This function is thread-safe and lock-free. Multiple threads can safely call this concurrently without external synchronization. The atom-based state ensures monotonicity across all threads within a single JVM process.
Monotonicity is only guaranteed within a single JVM process. For reliable time-ordering across multiple machines, use v7 UUIDs or Flakes which include additional entropy for distributed uniqueness.
Lock-free CAS (Compare-And-Swap) implementation with minimal overhead (~100-200ns vs System/currentTimeMillis).
Generate a guaranteed monotonically increasing timestamp. Returns a 60-bit timestamp in 100-nanosecond intervals since the Gregorian epoch (1582-10-15), used by UUID v1 and v6. ## Thread Safety This function is **thread-safe and lock-free**. Multiple threads can safely call this concurrently without external synchronization. The atom-based state ensures monotonicity across all threads within a single JVM process. ## Monotonicity Guarantees - **Within JVM**: Strictly monotonic - each call returns a value greater than all previous calls, even when called concurrently - **Clock skew**: Handles backward clock adjustments by spinning until time catches up - **Subcounter**: When called multiple times in the same millisecond, uses a subcounter (0-9999) to maintain monotonicity ## Distributed Systems Monotonicity is **only guaranteed within a single JVM process**. For reliable time-ordering across multiple machines, use v7 UUIDs or Flakes which include additional entropy for distributed uniqueness. ## Performance Lock-free CAS (Compare-And-Swap) implementation with minimal overhead (~100-200ns vs System/currentTimeMillis).
(monotonic-unix-time-and-random-counter)Generate guaranteed monotonically increasing timestamp and counter pairs.
Returns a vector [milliseconds counter] where milliseconds is Unix time and counter is a 12-bit value (0-4095). Used by UUID v7 for monotonic ordering.
This function is thread-safe and lock-free. Multiple threads can safely call this concurrently. The atom-based state ensures both the timestamp and counter maintain monotonic ordering across all threads.
Monotonicity is only guaranteed within a single JVM process. The random counter initialization provides some collision resistance across machines, but use Flakes for stronger distributed uniqueness guarantees.
Lock-free CAS implementation with minimal overhead. Counter exhaustion is rare (<0.001% at 4M ops/sec) due to 4096-value range per millisecond.
Generate guaranteed monotonically increasing timestamp and counter pairs. Returns a vector [milliseconds counter] where milliseconds is Unix time and counter is a 12-bit value (0-4095). Used by UUID v7 for monotonic ordering. ## Thread Safety This function is **thread-safe and lock-free**. Multiple threads can safely call this concurrently. The atom-based state ensures both the timestamp and counter maintain monotonic ordering across all threads. ## Monotonicity Guarantees - **Within JVM**: Strictly monotonic - each call returns [time, counter] pairs that are lexically greater than all previous calls - **Clock skew**: Handles backward clock adjustments by spinning until time catches up - **Counter behavior**: - On new millisecond: counter resets to random 8-bit value (0-255) - Within same millisecond: counter increments monotonically up to 4095 - Counter exhaustion: spins waiting for next millisecond ## Distributed Systems Monotonicity is **only guaranteed within a single JVM process**. The random counter initialization provides some collision resistance across machines, but use Flakes for stronger distributed uniqueness guarantees. ## Performance Lock-free CAS implementation with minimal overhead. Counter exhaustion is rare (<0.001% at 4M ops/sec) due to 4096-value range per millisecond.
Conversion factor from milliseconds to 100-nanosecond intervals.
UUID v1/v6 timestamps use 100-nanosecond intervals as the base unit. 1 millisecond = 10,000 × 100-nanosecond intervals
Conversion factor from milliseconds to 100-nanosecond intervals. UUID v1/v6 timestamps use 100-nanosecond intervals as the base unit. 1 millisecond = 10,000 × 100-nanosecond intervals
(posix-time)(posix-time gregorian)Generate the (Unix compatible) POSIX time -- the number of seconds that have elaspsed since 00:00 January 1, 1970 UTC
Generate the (Unix compatible) POSIX time -- the number of seconds that have elaspsed since 00:00 January 1, 1970 UTC
(universal-time)(universal-time gregorian)Generate the (Common-Lisp compatible) universal-time -- the number of seconds that have elapsed since 00:00 January 1, 1900 GMT
Generate the (Common-Lisp compatible) universal-time -- the number of seconds that have elapsed since 00:00 January 1, 1900 GMT
Milliseconds between Unix epoch (1970-01-01) and Universal Time epoch (1900-01-01).
Calculated as: 70 years × 365.25 days/year × 24 hours/day × 3600 seconds/hour × 1000 ms/second Value: 2,208,988,800,000 ms
Milliseconds between Unix epoch (1970-01-01) and Universal Time epoch (1900-01-01). Calculated as: 70 years × 365.25 days/year × 24 hours/day × 3600 seconds/hour × 1000 ms/second Value: 2,208,988,800,000 ms
Seconds between Unix epoch (1970-01-01) and Universal Time epoch (1900-01-01).
Calculated as: 70 years × 365.25 days/year × 24 hours/day × 3600 seconds/hour Value: 2,208,988,800 seconds
Seconds between Unix epoch (1970-01-01) and Universal Time epoch (1900-01-01). Calculated as: 70 years × 365.25 days/year × 24 hours/day × 3600 seconds/hour Value: 2,208,988,800 seconds
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |