{"action":"created","issue":{"url":"https://api.github.com/repos/s5z/zsim/issues/57","repository_url":"https://api.github.com/repos/s5z/zsim","labels_url":"https://api.github.com/repos/s5z/zsim/issues/57/labels{/name}","comments_url":"https://api.github.com/repos/s5z/zsim/issues/57/comments","events_url":"https://api.github.com/repos/s5z/zsim/issues/57/events","html_url":"https://github.com/s5z/zsim/issues/57","id":94342567,"number":57,"title":"waitUntilQueued times out due to the pin internal lock","user":{"login":"arodchen","id":12499660,"avatar_url":"https://avatars.githubusercontent.com/u/12499660?v=3","gravatar_id":"","url":"https://api.github.com/users/arodchen","html_url":"https://github.com/arodchen","followers_url":"https://api.github.com/users/arodchen/followers","following_url":"https://api.github.com/users/arodchen/following{/other_user}","gists_url":"https://api.github.com/users/arodchen/gists{/gist_id}","starred_url":"https://api.github.com/users/arodchen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/arodchen/subscriptions","organizations_url":"https://api.github.com/users/arodchen/orgs","repos_url":"https://api.github.com/users/arodchen/repos","events_url":"https://api.github.com/users/arodchen/events{/privacy}","received_events_url":"https://api.github.com/users/arodchen/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2015-07-10T16:35:42Z","updated_at":"2016-11-04T21:16:17Z","closed_at":null,"body":"When syscallLeave is called from SyscallEnter waitUntilQueued can time out if the woken thread is about to call SyscallEnter before reaching sleeping point on schedLock futex. The reason for that is that before calling the function registered in PIN_AddSyscallEntryFunction the pin client lock is obtained as it is written in the Pin documentation.\n\nIt is possible to move some functionality from SyscallEnter to another function without a lock by adding instrumentation on INS_IsSyscall condition. I tried to move call to syscallLeave to the unlocked function which is called before SyscallEnter but ZSim failed with panic(\"Wakeup race in barrier?\").\n\nDo you have any ideas how to solve that problem?\n"},"comment":{"url":"https://api.github.com/repos/s5z/zsim/issues/comments/258549534","html_url":"https://github.com/s5z/zsim/issues/57#issuecomment-258549534","issue_url":"https://api.github.com/repos/s5z/zsim/issues/57","id":258549534,"user":{"login":"gaomy3832","id":3386287,"avatar_url":"https://avatars.githubusercontent.com/u/3386287?v=3","gravatar_id":"","url":"https://api.github.com/users/gaomy3832","html_url":"https://github.com/gaomy3832","followers_url":"https://api.github.com/users/gaomy3832/followers","following_url":"https://api.github.com/users/gaomy3832/following{/other_user}","gists_url":"https://api.github.com/users/gaomy3832/gists{/gist_id}","starred_url":"https://api.github.com/users/gaomy3832/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gaomy3832/subscriptions","organizations_url":"https://api.github.com/users/gaomy3832/orgs","repos_url":"https://api.github.com/users/gaomy3832/repos","events_url":"https://api.github.com/users/gaomy3832/events{/privacy}","received_events_url":"https://api.github.com/users/gaomy3832/received_events","type":"User","site_admin":false},"created_at":"2016-11-04T21:16:17Z","updated_at":"2016-11-04T21:16:17Z","body":"I am not 100% on the scheduler logic, either. Let me try to explain my fix:\r\n\r\nIn your example without your fix, thread 2 will be woken up, and right after this wakeup, it is now inside the function `waitForContext()`. With my fix, the first thing this thread tries to do is to grab the `schedLock` regardless of anything. This will be detected by `waitUntilQueued()` of thread 1, and thus thread 1 won't be blocked by it, and can return the call chain that you listed, all the way back to `SyscallEnter()`, and also release the pin lock.\r\n\r\nThe key here is that `waitUntilQueued()` will only exit successfully if the wakee thread (thread 2) is waiting on the `schedLock`, which is used as the hint that thread 2 has been made running by the host OS, and joining the simulation scheduler (see the comments in #15). Without my fix, thread 2 may not wait on the `schedLock`, therefore even after it successfully joins the simulation, thread 1 won't detect that, and thus unnecessarily blocked in `waitUntilQueued()`. At some time, when thread 2 tries to acquire the pin lock, deadlock happens as you described.\r\n\r\nTo summary, I believe that as long as we enforce thread 2 to wait on the `schedLock` as the first thing after it is up, then thread 1 can quickly exit, and thus the deadlock won't happen.\r\n\r\nLet me know if anything is unclear. I love to discuss this so we all get better understanding of the code :)"}}
{"actor":{"display_login":"gaomy3832"}}