What does a deadlock mean in golang?

393 views
Skip to first unread message

伊藤和也

unread,
Jan 29, 2019, 3:55:17 AM1/29/19
to golang-nuts
I know the general meaning of a deadlock, but I don't know the meaning of a deadlock in golang. For example, I send 4 values to a buffered channel whose maxmum size is 3 and a deadlock occurs. I think this is just "values are out of bounds" like array. What does a deaklock mean in golang?
func main() {
ch1 := make(chan int, 3)
ch1<- 10
ch1<- 20
ch1<- 30
ch1<- 40
}

fatal error: all goroutines are asleep - deadlock!

diego patricio

unread,
Jan 29, 2019, 3:59:42 AM1/29/19
to 伊藤和也, golang-nuts
Hi,  maybe it's because no goroutine read the channel,  the four value cause the deadlock because for write that value there is no space in the channel,  sorry by my English, I'm new in go too... 

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ian Davis

unread,
Jan 29, 2019, 4:10:58 AM1/29/19
to golan...@googlegroups.com
It's because the goroutine executing the main function blocks until the last channel send completes. But since you don't have another goroutine receiving from the channel the program cannot continue and remains in a blocked state. This is the cause of the deadlock.

Ian Denhardt

unread,
Jan 29, 2019, 4:26:38 AM1/29/19
to kazya.i...@gmail.com, diego patricio, golang-nuts
Yes, exactly. It's a deadlock in the general sense, but this case is
particularly easy to detect: if all of the goroutines in your program
are blocked on some channel operation, then the runtime's scheduler
notices it has nothing it can do and reports that the system has
deadlocked.

-Ian

Quoting diego patricio (2019-01-29 03:59:13)
> Hi,� maybe it's because no goroutine read the channel,� the four
> value cause the deadlock because for write that value there is no space
> in the channel,� sorry by my English, I'm new in go too...�
>
> El mar., 29 ene. 2019 9:55, ���� <[1]kazya.i...@gmail.com>
> escribió:
>
> I know the general meaning of a deadlock, but I don't know the meaning
> of a deadlock in golang. For example, I send 4 values to a buffered
> channel whose maxmum size is 3 and a deadlock occurs. I think this is
> just "values are out of bounds" like array. What does a deaklock mean
> in golang?
> func main() {
> ch1 := make(chan int, 3)
> ch1<- 10
> ch1<- 20
> ch1<- 30
> ch1<- 40
> }
>
> fatal error: all goroutines are asleep - deadlock!
>
> --
> 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 [2]golang-nuts...@googlegroups.com.
> For more options, visit [3]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 [4]golang-nuts...@googlegroups.com.
> For more options, visit [5]https://groups.google.com/d/optout.
>
> Verweise
>
> 1. mailto:kazya.i...@gmail.com
> 2. mailto:golang-nuts...@googlegroups.com
> 3. https://groups.google.com/d/optout
> 4. mailto:golang-nuts...@googlegroups.com
> 5. https://groups.google.com/d/optout

伊藤和也

unread,
Jan 29, 2019, 4:59:12 AM1/29/19
to golang-nuts
I quoted 3 explanation about a deadlock from 3 websites. The ideo of the deadlock in golang and the explanations are the same or similar or different?

A deadlock is a situation in which two computer programs sharing the same resource are effectively preventing each other from accessing the resource, resulting in both programs ceasing to function. 
https://whatis.techtarget.com/definition/deadlock

In general computing, a deadlock is a situation where two different programs or processes depend on one another for completion, either because both are using the same resources or because of erroneous cues or other problems.https://www.techopedia.com/definition/2766/deadlock-computers


There was a time where operating systems were only able to execute a single process at a time, thus giving full system resource and attention to that one single process. Nowadays operating systems can handle multiple tasks at once, but sometimes they have to deal with a problem known as a deadlock. A deadlock occurs when there is at least one process, who is waiting for resources to be released by another process, in order to finish a task correctly. https://study.com/academy/lesson/what-is-deadlock-definition-examples-avoidance.html


2019年1月29日火曜日 17時55分17秒 UTC+9 伊藤和也:

伊藤和也

unread,
Jan 29, 2019, 5:00:33 AM1/29/19
to golang-nuts
I quoted 3 explanation about a deadlock from 3 websites. The idea of the deadlock in golang and the explanations are the same or similar or different?

A deadlock is a situation in which two computer programs sharing the same resource are effectively preventing each other from accessing the resource, resulting in both programs ceasing to function. 
https://whatis.techtarget.com/definition/deadlock

In general computing, a deadlock is a situation where two different programs or processes depend on one another for completion, either because both are using the same resources or because of erroneous cues or other problems.https://www.techopedia.com/definition/2766/deadlock-computers


There was a time where operating systems were only able to execute a single process at a time, thus giving full system resource and attention to that one single process. Nowadays operating systems can handle multiple tasks at once, but sometimes they have to deal with a problem known as a deadlock. A deadlock occurs when there is at least one process, who is waiting for resources to be released by another process, in order to finish a task correctly. https://study.com/academy/lesson/what-is-deadlock-definition-examples-avoidance.html



2019年1月29日火曜日 17時55分17秒 UTC+9 伊藤和也:
I know the general meaning of a deadlock, but I don't know the meaning of a deadlock in golang. For example, I send 4 values to a buffered channel whose maxmum size is 3 and a deadlock occurs. I think this is just "values are out of bounds" like array. What does a deaklock mean in golang?

Jan Mercl

unread,
Jan 29, 2019, 5:12:35 AM1/29/19
to 伊藤和也, golang-nuts
On Tue, Jan 29, 2019 at 10:59 AM 伊藤和也 <kazya.i...@gmail.com> wrote:

A deadlock is the same thing in any environment/any programming language: Waiting for something to happen that will provably not happen.

So yes, deadlock in Go is the same as deadlock anywhere else.

PS: Please do not paste colorized code. Particularly not with inverted colors. Some people cannot read it. Also, the name of the language is Go.

--

-j

Ian Lance Taylor

unread,
Jan 29, 2019, 9:47:16 AM1/29/19
to 伊藤和也, golang-nuts
On Tue, Jan 29, 2019 at 12:55 AM 伊藤和也 <kazya.i...@gmail.com> wrote:
>
> I know the general meaning of a deadlock, but I don't know the meaning of a deadlock in golang. For example, I send 4 values to a buffered channel whose maxmum size is 3 and a deadlock occurs. I think this is just "values are out of bounds" like array.

Sending a value on a buffered channel, where the buffer is full, is
not like an array "index out of bounds" error. Channels are not
arrays. If the buffer is full, the channel send will block until some
other goroutine receives a value from the channel.

Ian

Ian Denhardt

unread,
Jan 29, 2019, 2:25:51 PM1/29/19
to kazya.i...@gmail.com, golang-nuts
Quoting 伊藤和也 (2019-01-29 05:00:32)

> I know the general meaning of a deadlock, but I don't know the meaning
> of a deadlock in golang. For example, I send 4 values to a buffered
> channel whose maxmum size is 3 and a deadlock occurs. I think this is
> just "values are out of bounds" like array. What does a deaklock mean
> in golang?

A deadlock means the same thing in Go as it does in general; there's no
language-specific concept here.

The error you're seeing isn't an "out of bounds" error, rather, on the
last send the channel is already full so the sending goroutine waits until
there is space to insert the new item. Since there is nothing that will
ever take stuff out of the channel, this is never going to happen --
therefore you have a deadlock.

If you modify the program so there is another goroutine which will
receive a value from the channel:

package main

import (
"time"
)

func main() {
ch1 := make(chan int, 3)
go func() {
time.Sleep(10 * time.Second)
<-ch1
}()
ch1 <- 10
ch1 <- 10
ch1 <- 30
ch1 <- 40
}

then you won't get that error -- after the 10 second sleep, the spawned
goroutine will pull a value out of the channel, making space for one
more. At this point the send succeeds, the first goroutine is unblocked,
and the program finishes successfully.

Normally, the result of a deadlock is that things just hang, but because
channels are built-in to the language, and the compiler and runtime know
about them, it's possible for the runtime to spot certain patterns of
deadlocks. I mentioned this in another comment, but basically what's
happening is when the goroutine scheduler notices it doesn't have any
goroutines that are ready to run, it checks to see if any of them are
waiting on something that might unblock without the help of another
goroutine. If so, it waits until there's something to run. Otherwise it
reports an error, rather than just hanging.

In the first iteration of the program (in your original message), there
are no other goroutines at all, so when the scheduler sees that it's
only goroutine is waiting on a channel, it knows it will never finish
and bails.

In the modified version above, shortly after the program begins, the
original goroutine is again blocked on the channel send, but this time
there is another goroutine, which is blocked on a call to sleep. This
time, when the scheduler notices it has nothing to run, it also sees
that there is a goroutine waiting on sleep() -- which might finish
eventually, so it gives it some time, rather than aborting. When the
sleep completes, that goroutine can be scheduled and we're good.

It is of course possible to cause deadlocks that the runtime won't
catch; a variant of the above example that used os.Pipe() instead of
a channel would just hang, even though the same concurrency patterns
are at fault, because the goroutine scheduler doesn't know about pipes,
only channels.

-Ian

Wim Lewis

unread,
Jan 29, 2019, 2:55:23 PM1/29/19
to golang-nuts

On 29. jan. 2019, at 2:00 f.h., 伊藤和也 <kazya.i...@gmail.com> wrote:
> In general computing, a deadlock is a situation where two different programs or processes depend on one another for completion, either because both are using the same resources or because of erroneous cues or other problems.https://www.techopedia.com/definition/2766/deadlock-computers

This is the meaning here, although in Go you have to read it as "two different goroutines depend...". (It's a general concept and could apply to "programs", "threads of control", "goroutines", "processes", "tasks", etc.)

The example you posted only has one goroutine, but usually, "deadlock" refers to situations with at least two mutually-blocking processes. For example, maybe there is one routine that can't proceed until another routine consumes a value from the channel, but that other routine also can't proceed until the first does something.

The "dining philosophers problem" is sometimes used as an example: https://en.wikipedia.org/wiki/Dining_philosophers_problem


伊藤和也

unread,
Jan 29, 2019, 5:27:50 PM1/29/19
to golang-nuts

What "Ian Denhardt" says is quite reasonnable below.

The error you're seeing isn't an "out of bounds" error, rather, on the 
last send the channel is already full so the sending goroutine waits until 
there is space to insert the new item. Since there is nothing that will 
ever take stuff out of the channel, this is never going to happen -- 
therefore you have a deadlock. 

Normally, the result of a deadlock is that things just hang, 
 
Finally I understand it really really clearly but not just because of what "lan Denharbt" says but also what the others say. Thanks a lot. 

2019年1月29日火曜日 17時55分17秒 UTC+9 伊藤和也:

Tom Mitchell

unread,
Jan 30, 2019, 3:23:50 PM1/30/19
to 伊藤和也, golang-nuts
On Tue, Jan 29, 2019 at 12:55 AM 伊藤和也 <kazya.i...@gmail.com> wrote:
I know the general meaning of a deadlock, but I don't know the meaning of a deadlock in golang.

Good question...
A classic and now hard to find reference for a deadlock is "Operating System Principles (Prentice-Hall Series in Automatic Computation) by Per Brinch Hansen"
 
For example, I send 4 values to a buffered channel whose maxmum size is 3 and a deadlock occurs.

Yours is blocking I/O and not a programming error with semaphores, monitors  and mutual exclusion
of your own design.

Since the internals of Go detect this it seems correct but the run time detection would not reach out to 
other machines in the case of channel I/O abstracted to and on a  far away resource.  The message 
in all no progress cases likely should have a unique error.  If an event could unblock this then the presence
of an event handler is or is not checked.  Timers... ?

Interesting.   




--
   T o m    M i t c h e l l

Bakul Shah

unread,
Jan 30, 2019, 3:42:26 PM1/30/19
to Tom Mitchell, 伊藤和也, golang-nuts
On Wed, 30 Jan 2019 12:21:46 -0800 Tom Mitchell <mi...@niftyegg.com> wrote:
>
> On Tue, Jan 29, 2019 at 12:55 AM =E4=BC=8A=E8=97=A4=E5=92=8C=E4=B9=9F <kazy=
> a.ito...@gmail.com> wrote:
>
> > I know the general meaning of a deadlock, but I don't know the meaning of
> > a deadlock in golang.
> >
>
> Good question...
> A classic and now hard to find reference for a deadlock is "Operating
> System Principles (Prentice-Hall Series in Automatic Computation) by Per
> Brinch Hansen"
>

This is the classic paper on Deadlocks:

http://www.ccs.neu.edu/home/pjd/cs7600-s10/Tuesday_January_26_01/p67-coffman.pdf

@article{Coffman:1971:SD:356586.356588,
author = {Coffman, E. G. and Elphick, M. and Shoshani, A.},
title = {System Deadlocks},
journal = {ACM Comput. Surv.},
issue_date = {June 1971},
volume = {3},
number = {2},
month = jun,
year = {1971},
issn = {0360-0300},
pages = {67--78},
numpages = {12},
url = {http://doi.acm.org/10.1145/356586.356588},
doi = {10.1145/356586.356588},
acmid = {356588},
publisher = {ACM},
address = {New York, NY, USA},
}

Michael Jones

unread,
Jan 30, 2019, 3:52:19 PM1/30/19
to Bakul Shah, Tom Mitchell, 伊藤和也, golang-nuts
fantastic read!

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
Michael T. Jones
michae...@gmail.com
Reply all
Reply to author
Forward
0 new messages