票证锁定是否有界免等待? (在某些假设下)

发布于 2024-12-09 09:29:14 字数 803 浏览 0 评论 0原文

我正在讨论的票证锁可能如下所示(伪 C 语法):

    unsigned int ticket_counter = 0, lock_counter = 0;

void lock() {
    unsigned int my_ticket = fetch_and_increment(ticket_counter);

    while (my_ticket != lock_counter) {}
}

void unlock() {
    atomic_increment(lock_counter);
}

让我们假设这样的票证锁同步对无等待的关键部分 S 的访问,即执行关键部分恰好需要 c 个周期/指令。假设系统中最多有p个线程,那么S使用票证锁的同步是有界无等待的吗?

在我看来,是的,因为票锁是公平的,因此等待的上限是 O(p * c)。

我犯错了吗?我有点困惑。我一直认为锁定意味着不是(有界)无等待,因为以下语句: “不可能从一组原子寄存器构造队列、堆栈、优先级队列、集合或列表的无等待实现。” (《多处理器编程艺术》中的推论 5.4.1,Herlihy 和 Shavit)

但是,如果票证锁(可能还有任何其他公平锁定机制)在上述假设下是有界无等待的,则它(可能)能够构建 队列、堆栈等的有界无等待实现。(这就是我实际面临的问题。)


回想一下《多处理器编程的艺术》中有界无等待的定义, Herlihy 和 Shavit 第 59 页:

“如果一个方法保证每个调用在有限数量的步骤中完成其执行,则该方法是无等待的。如果方法调用的步骤数有限制,则该方法是有界无等待的可以拿。”

I am talking about a ticket lock that might look as follows (in pseudo-C syntax):

    unsigned int ticket_counter = 0, lock_counter = 0;

void lock() {
    unsigned int my_ticket = fetch_and_increment(ticket_counter);

    while (my_ticket != lock_counter) {}
}

void unlock() {
    atomic_increment(lock_counter);
}

Let's assume such a ticket lock synchronizes access to a critical section S that is wait-free, i.e. executing the critical section takes exactly c cycles/instructions. Assuming, that there are at most p threads in the system, is the synchronization of S using the ticket lock bounded wait-free?

In my opinion, it is, since the ticket lock is fair and thus the upper bound for waiting is O(p * c).

Do I make a mistake? I am little bit confused. I always thought locking implies not to be (bounded) wait-free because of the following statement:
"It is impossible to construct a wait-free implementation of a queue, stack, priority queue, set, or list from a set of atomic register." (Corollary 5.4.1 in Art of Multiprocessor Programming, Herlihy and Shavit)

However, if the ticket lock (and maybe any other fair locking mechanism) is bounded wait-free under the mentioned assumptions, it (might) enables the construction of bounded wait-free implementations of queue, stack, etc. (That's the question I am actually faced with.)


Recall the definition of bounded wait-free in "Art of Multiprocessor Programming", p.59 by Herlihy and Shavit:

"A method is wait-free if it guarantees that every call finishes its execution in a finite number of steps. It is bounded wait-free if there is a bound on the number of steps a method call can take."

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

桃酥萝莉 2024-12-16 09:29:14

好吧,我相信你是对的,但有一些警告。

也就是说,有界无等待属性仅在临界区 S 是非抢占式的情况下才成立,我想您只能保证内核空间代码(通过禁用临界区中的中断)。否则,当一个线程位于临界区时,操作系统可能会决定切换到另一个线程,然后等待时间是无限的,不是吗?

另外,对于内核代码,我认为 p 不是软件线程的数量,而是硬件线程的数量(或核心,对于不支持每个 CPU 核心多个线程的 CPU)。因为一次最多有 p 个软件线程可以运行,并且由于 S 是非抢占式的,因此没有等待锁的睡眠线程。

Well, I believe you are correct, with some caveats.

Namely, the bounded wait-free property holds only if the critical section S is non-preemptive, which I suppose you can guarantee only for kernel space code (by disabling interrupts in the critical section). Otherwise the OS might decide to switch to another thread while one thread is in the critical section, and then the wait time is unbounded, no?

Also, for kernel code, I suppose p is not the number of software threads but rather the number of hardware threads (or cores, for CPU's that don't support several threads per CPU core). Because at most p software threads will be runnable at a time, and as S is non-preemptive you have no sleeping threads waiting on the lock.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文