Acquiring a mutex while pinned can cause deadlock because pinning prevents a stop-the-world. For example, the following sequence could result in a deadlock:
M1: Acquires mutex l. M2: Pins the M. M2: Attempts to acquire mutex l. M3: Initiates stop-the-world M3: Stops M1 M3: Attempts to stop M2, but can't because M2 is pinned. At this point, M1 can't make progress to release mutex l because M3 stopped it, which means M2 won't be able to finish acquiring the mutex (so it will never release the pin), which means M3 won't be able to finish stopping the world (so it will never start M1 back up). On Mon, Apr 8, 2019 at 2:31 AM Cholerae Hu <cholerae...@gmail.com> wrote: > I'm reading this commit > https://github.com/golang/go/commit/d5fd2dd6a17a816b7dfd99d4df70a85f1bf0de31 . > Inside runtime_procPin we only increases the m.lock count, why will it > cause deadlock when acquiring a mutex after pin? > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
