This video is well worth watching, pausing and rewinding as required. It's
Bryan C. Mills "Rethinking Classical Concurrency Patterns":
https://www.youtube.com/watch?v=5zXAHh5tJqQ
It shows patterns which are tricky to implement correctly with condition
variables and semaphores can be cleanly impl
On Fri, Jul 19, 2024 at 2:05 PM Laurence Guild
wrote:
> well, if I am trying to learn golang then I may need examples of how to
> use sync.Cond, but it's good to know that it may have problems. If you have
> an interview then people may ask you questions and if you haven't tried to
> use some fea
well, if I am trying to learn golang then I may need examples of how to use
sync.Cond, but it's good to know that it may have problems. If you have an
interview then people may ask you questions and if you haven't tried to use
some feature or haven't played with it then you may feel like you don
On Fri, Jul 19, 2024 at 1:52 PM Laurence Guild wrote:
>
>
> Is there an article that says not to use sync.Cond ? This page seems to have
> some fans of sync.Cond. I have xtensive software experience but I am new to
> golang so I am just trying to learn
>
> https://github.com/golang/go/issues/21
Is there an article that says not to use sync.Cond ? This page seems to
have some fans of sync.Cond. I have xtensive software experience but I am
new to golang so I am just trying to learn
https://github.com/golang/go/issues/21165
On Thursday, July 18, 2024 at 9:33:57 PM UTC-4 王旭东 wrote:
> H
Hi,
It’s better to not use sync.Cond. Instead, use a channel to do a jame job.
There is even a issue to discuss remove it.
在2024年7月19日星期五 UTC+8 04:07:26 写道：
> But I think that Done() is for the outer which prevents the broadcast. By
> putting it in the defer all of the subscribers should be wai
But I think that Done() is for the outer which prevents the broadcast. By putting it in the defer all of the subscribers should be waiting on the condition when it occurs. Caveat- not looking at code - just remembering. On Jul 18, 2024, at 3:01 PM, Lammie Jonson wrote:>> defer goroutineRunning.Do
>> defer goroutineRunning.Done()
This doesn't work. Each invocation of subscribe() has it's own
sync.WaitGroup. It's just used it appears to ensure that the enclosed
goroutine is running before subscribe() returns
--
You received this message because you are subscribed to the Google Groups
To clarify, the inner Go routine calls Done() at the start, so the main can get
to the Broadcast before the inners are waiting.
Which is what Jan’s fix will fix :) (pretty sure)
> On Jul 18, 2024, at 10:20 AM, robert engels wrote:
>
> Because the wait on the condition is in another Go routine,
Because the wait on the condition is in another Go routine, so the the
Broadcast occurs before all of the routines are waiting. Broadcast only wakes
up currently waiting routines.
> On Jul 18, 2024, at 9:01 AM, Lammie Jonson wrote:
>
> // I am not sure why this code sometimes deadlocks, but so
On Thu, Jul 18, 2024 at 4:24 PM Lammie Jonson wrote:
> goroutineRunning.Done()
Should be
defer goroutineRunning.Done()
(not tested)
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop rece
// I am not sure why this code sometimes deadlocks, but sometimes it
doesn't.
// Hopefully someone will have some suggestions
package main
// ??? sometimes deadlocks
import (
"fmt"
"sync"
"time"
)
type Button struct {
Clicked *sync.Cond
}
func main() {
button := Button{
12 matches
Mail list logo
