yes, 'synchronize' uses a try_lock/backoff algorithm, same as std::scoped_lock.

edit: it could theoretically livelock, but I believe most if not all STM implementations also do not guarantee forward progress.

▲

kragen 2 hours ago | parent [-]

Purely optimistic STM implementations that abort transactions early and don't permit other transactions to read uncommitted data can guarantee forward progress, and I believe that both Haskell's STM and Fraser and Harris's STM do, though I could easily be mistaken about that.

▲

gpderetta an hour ago | parent [-]

Probably you are right. I vaguely remembered the "Why Transactional Memory Should Not Be Obstruction-Free" paper, but I might have misunderstood or forgotten what it meant (the implementation can be non obstruction-free, but it doesn't mean it can live-lock).

	▲	kragen an hour ago \| parent [-]
		You avoid livelock, as I understand the term in an STM, if the only thing that can prevent a transaction from committing when it tries to commit is some other transaction having committed. That way, forward progress is guaranteed; as long as some transaction commits, you're not livelocked, are you? I'm not familiar with "obstruction-free"ness; should I be?