具有并发分配器的空闲列表

发布于 2024-08-18 09:01:34 字数 90 浏览 8 评论 0原文

空闲列表是通过重用已分配的现有内存来加速分配的常见方法。有没有一种方法可以在并发分配器中使用空闲列表,而不会产生每次分配的锁定开销(这会抵消空闲列表的预期性能增益)?

Freelists are a common way to speed up allocation by reusing existing memory that was already allocated. Is there a way to use free-lists in a concurrent allocator, without incurring the overhead of a lock for every allocation (which would neutralize the intended performance gain of the freelist)?

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

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

发布评论

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

评论(2

夕嗳→ 2024-08-25 09:01:34

您可以拥有特定于线程的空闲列表块。

基本上,有一些系统可以填充空闲列表(例如垃圾收集器)。然后每个线程都可以有自己的空闲列表块,其中包含少量条目。锁定将用于分配新块。对于包含 30 个条目的块,每 30 次分配只需锁定一次。相反,对于特定于线程的块,您可能必须更快地运行 GC,因为即使某些特定于线程的块仍然有一些空闲条目,共享列表也可能会变空。

You could have thread-specific free list chunks.

Basically, there is some system which populates the free lists (e.g. a garbage collector). Then each thread could have its own free list chunk, containing a small number of entries. Locking would be used to allocate a new chunk. With chunks with 30 entries, you would lock only once every 30 allocations. Conversely, with thread-specific chunks you may have to run the GC sooner, because the shared list could become empty even if some of the thread-specific chunks still have some free entries.

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