RE: [go-nuts] infinite loop makes program stuck
You are right. I misread that totally. Thanks! John John Souvestre - New Orleans LA From: Matt Harden [mailto:matt.har...@gmail.com] Sent: 2016 October 12, Wed 20:03 To: Minglangjun Li; John Souvestre Cc: golang-nuts Subject: Re: [go-nuts] infinite loop makes program stuck On Wed, Oct 12, 2016 at 1:33 AM Minglangjun Li wrote: On Wed, Oct 12, 2016 at 11:53 AM, Jesse McNelis wrote: If you have multiple CPUs (and the Go memory model assumes that you always can) they won't even write updated values from their cache out to main memory until they hit a lock. The reading CPU has read a value from main memory and put it in it's cache, it assumes that value won't change in main memory unless it hits a lock of it's own. If you don't lock then both CPUs will just sit in their own little world updating and reading values in their own caches and are never aware of each other. Thanks Jesse. Good to know that. On Wed, Oct 12, 2016 at 3:26 PM, John Souvestre wrote: I see that others have already addressed the locking issued, but I noticed something else. I don’t understand why you are using “select”. With only one case, I think that it’s normally going to fail and exit the select block, then loop due to the “for”. This will make it run constantly. That's not true. One of the select cases has to be satisfied; there is no failure. If there were a default case, that would be selected if no other case is ready. Without a default case, the select will block until one of the cases is ready. A single-case select can be replaced with a single send statement or receiving into a variable. If you get rid of the “select” then the loop will block until something comes in from the channel. John John Souvestre - New Orleans LA Please forgive me for that. I haven't been familiar with Go. -- 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. -- 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.
Re: [go-nuts] infinite loop makes program stuck
On Wed, Oct 12, 2016 at 1:33 AM Minglangjun Li wrote: > On Wed, Oct 12, 2016 at 11:53 AM, Jesse McNelis > wrote: > > If you have multiple CPUs (and the Go memory model assumes that you > always can) they won't even write updated values from their cache out > to main memory until they hit a lock. > The reading CPU has read a value from main memory and put it in it's > cache, it assumes that value won't change in main memory unless it > hits a lock of it's own. > > If you don't lock then both CPUs will just sit in their own little > world updating and reading values in their own caches and are never > aware of each other. > > > Thanks Jesse. Good to know that. > > On Wed, Oct 12, 2016 at 3:26 PM, John Souvestre > wrote: > > I see that others have already addressed the locking issued, but I noticed > something else. I don’t understand why you are using “select”. With only > one case, I think that it’s normally going to fail and exit the select > block, then loop due to the “for”. This will make it run constantly. > > That's not true. One of the select cases has to be satisfied; there is no failure. If there were a default case, that would be selected if no other case is ready. Without a default case, the select will block until one of the cases is ready. A single-case select can be replaced with a single send statement or receiving into a variable. > If you get rid of the “select” then the loop will block until something > comes in from the channel. > > > > John > > John Souvestre - New Orleans LA > > > Please forgive me for that. I haven't been familiar with Go. > > -- > 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. > -- 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.
Re: [go-nuts] infinite loop makes program stuck
On Wed, Oct 12, 2016 at 11:53 AM, Jesse McNelis wrote: > If you have multiple CPUs (and the Go memory model assumes that you > always can) they won't even write updated values from their cache out > to main memory until they hit a lock. > The reading CPU has read a value from main memory and put it in it's > cache, it assumes that value won't change in main memory unless it > hits a lock of it's own. > > If you don't lock then both CPUs will just sit in their own little > world updating and reading values in their own caches and are never > aware of each other. > Thanks Jesse. Good to know that. On Wed, Oct 12, 2016 at 3:26 PM, John Souvestre wrote: > I see that others have already addressed the locking issued, but I noticed > something else. I don’t understand why you are using “select”. With only > one case, I think that it’s normally going to fail and exit the select > block, then loop due to the “for”. This will make it run constantly. > > > > If you get rid of the “select” then the loop will block until something > comes in from the channel. > > > > John > > John Souvestre - New Orleans LA > Please forgive me for that. I haven't been familiar with Go. -- 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.
RE: [go-nuts] infinite loop makes program stuck
I see that others have already addressed the locking issued, but I noticed
something else. I don’t understand why you are using “select”. With only one
case, I think that it’s normally going to fail and exit the select block, then
loop due to the “for”. This will make it run constantly.
If you get rid of the “select” then the loop will block until something comes
in from the channel.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of liminglang...@gmail.com
Sent: 2016 October 11, Tue 21:26
To: golang-nuts
Subject: [go-nuts] infinite loop makes program stuck
Hi, there. I've read the FAQ and specifically the concurrency part. Tell me if
the problem has been discussed anywhere.
I used an infinite loop to block a goroutine until a value is big enough:
for commitIndex < index {}
I know its bad but its just a very intuitive and fast to implement. And I
incremented commitIndex in another goroutine monotonically:
for {
select {
case <-ch:
mu.Lock()
commitIndex++
mu.Unlock()
}
}
These are the only two places that access commitIndex. I didn't acquire the
lock when reading commitIndex since I think its OK to read a stale value in my
case. The program is a complex Raft replicated server so there're many other
goroutines. The problem is the program became stuck after running for a while.
commitIndex stopped updating and even the Raft servers stopped communicating
with each other. I ended up adding a Sleep() in the for loop and everything
worked. Is this normal? Or there's a problem with the goroutine scheduling?
--
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.
--
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.
Re: [go-nuts] infinite loop makes program stuck
On Wed, Oct 12, 2016 at 1:26 PM, wrote: > These are the only two places that access commitIndex. I didn't acquire the > lock when reading commitIndex since I think its OK to read a stale value in > my case. Remember that locking is communication. Saying, "I never poll the http server, it's ok if I have a stale value" is silly if you're expecting to know if that value on the server ever changes. If you have multiple CPUs (and the Go memory model assumes that you always can) they won't even write updated values from their cache out to main memory until they hit a lock. The reading CPU has read a value from main memory and put it in it's cache, it assumes that value won't change in main memory unless it hits a lock of it's own. If you don't lock then both CPUs will just sit in their own little world updating and reading values in their own caches and are never aware of each other. -- 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.
Re: [go-nuts] infinite loop makes program stuck
On Tue, Oct 11, 2016 at 7:26 PM, wrote:
> Hi, there. I've read the FAQ and specifically the concurrency part. Tell me
> if the problem has been discussed anywhere.
>
> I used an infinite loop to block a goroutine until a value is big enough:
>
> for commitIndex < index {}
>
> I know its bad but its just a very intuitive and fast to implement. And I
> incremented commitIndex in another goroutine monotonically:
>
> for {
> select {
> case <-ch:
> mu.Lock()
> commitIndex++
> mu.Unlock()
> }
> }
>
> These are the only two places that access commitIndex. I didn't acquire the
> lock when reading commitIndex since I think its OK to read a stale value in
> my case. The program is a complex Raft replicated server so there're many
> other goroutines. The problem is the program became stuck after running for
> a while. commitIndex stopped updating and even the Raft servers stopped
> communicating with each other. I ended up adding a Sleep() in the for loop
> and everything worked. Is this normal? Or there's a problem with the
> goroutine scheduling?
That is normal. Do not write code this way. Do not omit required locks.
Ian
--
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.
