I have two questions about the scheduler of golang

Getting Help
1
  1. Is golang’s syscall function asynchronous?
  2. Does the scheduler guarantee that there is no chance for any go routine to be starving?
2 Likes
2

Very appreciate for any answer :slight_smile:

2 Likes
3

There is a package syscall. Which of the functions in this package do you mean?

2 Likes
4

I mean the nature for all syscalls within a go routine

2 Likes
5

They are synchronous operations, you had no way to return the result of the syscall otherwise, but all of them return some value.

Be aware though that most of the syscalls will affect all go routines, rather than only the current one, as the systems kernel has no notion of go routines, it only sees the scheduler processes.

Also, there is nothing that prevents starving of single go routines, but the go runtime recognises deadlocks quite well and will panic at runtime when the hole system is deadlocked.

3 Likes
6

May be what I said about golang’s syscalll asynchronous is a little ambiguous.
Let me make it clear:

As long as I understand golang correctly, the internal of golang uses multithreads, so why not implement it in a way that when a goroutine need do a syscall, the thread which contains the goroutine (let’s call it thread A) just put a syscall request to a queue, then schedule others goroutine within thread A. after that, A worker thread (called thread B) can get the request from the queue, do the syscall and notify thead A
after the syscall returns, so thread A can wake the goroutine now.

This way, the thread contains go routine is doing syscall asynchronous.

What i want to know is: what’s the real implementation？

1 Like
7

In can’t work that way.

Golang use worker threads. You can have 10000 go routines, but you will only have a handfull worker threads. When a go routine does a blocking syscall, the worker thread is blocked until completion of the syscall. There is thus one worker thread less during the blocking syscall. This is what @NobbZ explained.

While the go routine and the worker thread are blocked on the syscall, other worker threads can run the other go routines.

I guess that syscalls are synchronous for efficiency reason. If requests had to be queued and processed asynchronously, it would introduce a latency in syscall execution. Synchronous syscalls is simple, efficient and work well as long as we have enough worker threads and very few blocking syscalls.

2 Likes
8

That’s very clear, thanks for your explanations. :grinning:

1 Like
9

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.