libextra: Rewrite MutexArc
#11708
libextra: Rewrite MutexArc
#11708
Conversation
| /// Called when the Arc is poisoned. This is out of line to guide | ||
| /// inlining. | ||
| #[inline(never)] | ||
| fn die_from_poison() -> ! { |
There was a problem hiding this comment.
Don't we have a #[cold] attribute as well?
There was a problem hiding this comment.
(Doesn't/shouldn't any function that never returns (-> !) automatically count as freezing cold?)
There was a problem hiding this comment.
Did you actually see a measureable improvement by marking this inline(never)? It'll already almost never be inlined because it's not cross-crate instantiated (no type parameters like the mutex).
Recently I've seen failing code have excellent codegen.
There was a problem hiding this comment.
AFAIK the fact that it's noreturn should make it be considered cold and seems to prevent inlining when I test.
|
This looks pretty awesome! I'm curious if we should worry about the removal of the attached condition variable, but that's probably another flavor of arc. I would expect a |
|
I remembered this morning that this does remove the cvar from inside the mutex, which is a little worrisome to me. We'd be required to write a more efficient cvar (like a mutex), but that should in theory be much easier. I think that it could be added in a backwards compatible way, I'm thinking that the |
|
@alexcrichton Yes, but it needs to be done carefully. According to http://pubs.opengroup.org/onlinepubs/9699919799/: "When a thread waits on a condition variable, having specified a particular mutex to either the pthread_cond_timedwait() or the pthread_cond_wait() operation, a dynamic binding is formed between that mutex and condition variable that remains in effect as long as at least one thread is blocked on the condition variable. During this time, the effect of an attempt by any thread to wait on that condition variable using a different mutex is undefined. Once all waiting threads have been unblocked (as by the pthread_cond_broadcast() operation), the next wait operation on that condition variable shall form a new dynamic binding with the mutex specified by that wait operation. [...]" So unless one determines that this is not actually a problem on all implementations, then a safe interface will also need to enforce this itself. |
|
I closed #11610 for now, so I'm going to close this one as well, sadly (needs the mutex rewrite first). |
r? @alexcrichton