From 3f24eb432a68c5bbec8b408d77f13cb571c49bfa Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Fri, 2 Jun 2023 11:48:55 +0200 Subject: [PATCH 1/1] publish Tree Borrows post --- .../tree-borrows.md => _posts/2023-06-02-tree-borrows.md} | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) rename personal/{_drafts/tree-borrows.md => _posts/2023-06-02-tree-borrows.md} (97%) diff --git a/personal/_drafts/tree-borrows.md b/personal/_posts/2023-06-02-tree-borrows.md similarity index 97% rename from personal/_drafts/tree-borrows.md rename to personal/_posts/2023-06-02-tree-borrows.md index ede3c0f..3c4f0c7 100644 --- a/personal/_drafts/tree-borrows.md +++ b/personal/_posts/2023-06-02-tree-borrows.md @@ -10,6 +10,7 @@ Indeed there is, but Stacked Borrows is just one proposal for a possible aliasin The purpose of Tree Borrows is to take the lessons learned from Stacked Borrows to build a new model with fewer issues, and to take some different design decisions such that we get an idea of some of the trade-offs and fine-tuning we might do with these models before deciding on the official model for Rust. Neven has written a detailed introduction to Tree Borrows [on his blog](https://perso.crans.org/vanille/treebor/), which you should go read first. +He presented this talk at a recent RFMIG meeting, so you can also [watch his talk here](https://www.youtube.com/watch?v=zQ76zLXesxA). In this post, I will focus on the differences to Stacked Borrows. I assume you already know Stacked Borrows and want to understand what changes with Tree Borrows and why. @@ -181,6 +182,7 @@ This optimization is possible without having any special aliasing model, so SB n If it weren't for the stack-violating hack that already came up several times above, I think there would be a fairly easy way of fixing this problem in SB, but alas, that hack is load-bearing and too much existing code is UB if we remove it. Meanwhile, TB does not need any such hack, so we can do the Right Thing (TM): when doing a read, unrelated mutable references are not entirely disabled, they are just made read-only. This means that "read shared reference, then read mutable reference" is equivalent to "read mutable reference, then read shared reference" and the optimization is saved. +(A consequence of this is that retags can also be reordered with each other, since they also act as reads. Hence the order in which you set up various pointers cannot matter, until you do the first write access with one of them.) ## Future possibility: `Unique` @@ -216,4 +218,4 @@ Neven has implemented Tree Borrows in Miri, so you can play around with it and c If you run into any surprises or concerns, please let us know! The [t-opsem Zulip](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem) and the [UCG issue tracker](https://github.com/rust-lang/unsafe-code-guidelines/) are good places for such questions. -That's all I got, thanks for reading -- and shout outs to Neven for doing all the actual work here, supervising this project has been a lot of fun! +That's all I got, thanks for reading -- and a shout out to Neven for doing all the actual work here (and for giving feedback on this blog post), supervising this project has been a lot of fun! -- 2.30.2