Is deadlock unsafe?

[bblum]

arc::exclusive is marked unsafe because it can deadlock trivially. But it's not too hard to use comm::port to deadlock too, and marking our core communication mechanism as unsafe is probably unwise.

Before removing the unsafe tag from exclusive.with(), though, perhaps we should think up a way to use borrowck to enforce that you don't call with within a with on the same exclusive (or maybe make them support recursive locking!!). Of course we can't statically prevent multi-exclusive deadlock, but the trivial ones might be doable.

[nikomatsakis]

Perhaps we could implement arc::exclusive in a way that does not trivially deadlock? I believe the problem is that it uses pthread mutexes and are scheduler in unaware of those. It seems like we should implement mutexes in our scheduler if we need them in our implementation.

[nikomatsakis]

Also, I believe that the use of unsafe here is appropriate. It's not because the arc::exclusive can deadlock---it's because it will deadlock unless you have an intimate understanding of the internals of our scheduler.

[bblum]

Oh, that's right - the will-deadlock-because-scheduler is the first bullet in #2781. I've also got a properly-blocking mutex implementation (in pursuit of #2795) in my stash that might help solve it (though not on its own).

[eholk]

@pcwalton mentioned this morning that if we get message passing fast enough, we might be able to do mutable state as a task where all messages sent to it have a yield-to-target mode. It'd let us remove arc::exclusive, which would make me happy.

[bblum]

Exclusives will always be unsafe because putting exclusives inside of exclusives can result in exchange heap leaks. Yet exclusives-in-exclusives might be desirable in some cases, so even if we could use the type system to prevent it (which seems infeasible), we shouldn't.

Conclusion: They stay unsafe.