Opened 19 years ago
Closed 13 years ago
#193 closed Feature Requests (invalid)
Check ordering for mutexes
| Reported by: | elfring | Owned by: | jsiek |
|---|---|---|---|
| Milestone: | Component: | concept_check | |
| Version: | None | Severity: | Showstopper |
| Keywords: | Cc: |
Description
The answer to the question "http://boost.org/libs/thread/doc/faq.html#question4" seems to be a good candidate for a new concept check or "allocator". Always lock mutexes in the same order.
Change History (2)
comment:1 by , 14 years ago
| Severity: | → Showstopper |
|---|
comment:2 by , 13 years ago
| Resolution: | None → invalid |
|---|---|
| Status: | assigned → closed |
Since this ticket doesn't really make any sense, I'm closing it. If anyone is still interested in it and has a more specific idea of what it means, feel free to reopen.
Note:
See TracTickets
for help on using tickets.
The link to the faq doesn't work any more. Here's the new link http://www.boost.org/doc/libs/1_31_0/libs/thread/doc/faq.html#question4
Also, I fail to see what locking mutexes in order has to do with concept checks and "allocators" (see #100 for the idea of an "allocator" used here). How can you check runtime constraints across functions at compile time? How does a mechanism for acquiring and releasing resources help to control the order in which resources are acquired?
Can we just close this ticket?