Как поток может вернуться в место, отличное от того, из которого он пришел в C#?

Question

Как поток мог вернуться в место, отличное от того, из которого он пришел в C#?

Я встретил следующую выдержку в CLR через C# книгу:

Всякий раз, когда вы получаете трассировку стека, вы можете обнаружить, что некоторые методы в реальном стеке вызовов не отображаются в строке трассировки стека. Для этого есть две причины. Во-первых, стек на самом деле является записью того, куда должен возвращаться поток, а не откуда пришел поток. Во-вторых, компилятор JIT (Just-in-Time) может встроить методы, чтобы избежать накладных расходов. вызов и возврат из отдельного метода.

Означает ли отрывок, что поток может вернуться не туда, откуда он пришел, или он что-то еще? В первом случае, может ли кто-нибудь привести пример, когда поток не возвращается туда, откуда он появился, пожалуйста? И в последнем случае, может кто-нибудь объяснить, что это значит безошибочно, пожалуйста?

Для меня выдержка сбивает с толку, потому что я привык к поведению операторов return в функциях - они всегда возврат к звонящему - место, откуда берутся нити, и я не могу представить себе случай, когда они вернутся в другое место. Это как-то связано с сахаром async/await syntacti c?

Answer 1

В отрывке делается вывод о том, что адрес возврата помещается в стек: это действительно адрес возврата, а не адрес источника перехода.

Другой способ взглянуть на это этот вызов не должен сочетаться с возвратом: вместо call-return вы можете использовать push-jump-return, что приведет вас к месту, которое вы нажали, а не к месту, из которого вы прыгнули.

Answer 2

Давайте подумаем об этом сценарии:

Поток A запускает Поток B.

Поток B запускается и продолжает свою работу в Потоке C.

Теперь это " возвращается "в тему C, несмотря на то, что она пришла из темы А.