Thanks austin! I totally understand. 在 2019年4月9日星期二 UTC+8下午10:59:37，Austin Clements写道： > > 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 <chole...@gmail.com > <javascript:>> 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 golan...@googlegroups.com <javascript:>. >> 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.
