Проблема с tickers в go

Добрый день, я надеюсь, что они могут поддерживать меня. Я делаю dummy, чтобы тестировать tickers в go:

package main
import(
    "fmt"
    "time"
)
func main(){
    ticker := time.NewTicker(time.Millisecond * 500) 
    go func() {
        for t := range ticker.C { 
            fmt.Println("Tic a las", t)
        }
    }()
    time.Sleep(time.Millisecond * 1500) 
    ticker.Stop()
    fmt.Println("Ticker detenido:", time.Now())

    var input string
    fmt.Scanln(&input)
    fmt.Println("done")
}

Теоретически ticker выполняет каждые 500 миллисекунд и я это останавливаю, переместив 1500 миллисекунд, из-за которого он был бы должен появляться 3 типа печати ticker (теоретически). Однако я получил следующий вывод:

Tic a las 2016-04-13 09:56:11.8632579 -0500 CDT
Tic a las 2016-04-13 09:56:12.363399 -0500 CDT
Ticker detenido: 2016-04-13 09:56:12.8634635 -0500 CDT

Так что, я добавил последние 3 линии кода, чтобы заканчивать программу, когда нажмут на клавишу, и пытаться снова я встретился с этим:

Tic a las 2016-04-13 10:08:15.4709006 -0500 CDT
Tic a las 2016-04-13 10:08:15.9713121 -0500 CDT
Ticker detenido: 2016-04-13 10:08:16.4714132 -0500 CDT
Tic a las 2016-04-13 10:08:16.4714132 -0500 CDT

Поскольку они могут наблюдать последние две линии, они печатают 2016-04-13 10:08:16.4714132, та же дата час даже в миллисекундах, но работает сначала печать main и мне нужно, чтобы была напечатана сначала печать ticker. Есть какой-то способ это исправлять? Какой-то способ давать ему первенство трэду ticker на main? Я надеюсь, что они могут поддерживать меня Спасибо и привет

1
задан 13.04.2016, 18:18
1 ответ

Возвращаясь в твою первую попытку я вижу, что все "хорошо".

package main

import(
    "fmt"
    "time"
)

func main(){
    ticker := time.NewTicker(time.Millisecond * 500) 
    go func() {
        for t := range ticker.C { 
            fmt.Println("Tic a las", t)
        }
    }()
    time.Sleep(time.Millisecond * 1500) 
    ticker.Stop()
    fmt.Println("Ticker detenido:", time.Now())
}

Многообразные разы когда это выполняют, ты ощутишься, что часто он печатает две линии, как ты поместил в твоем вопросе, и другие разы он печатает три линии (в обоих случаях, не считая линии Tic detenido).

То, за чем оно последует, что последний Tic происходи в то же время, что ticker.Stop и иногда он не даст время печатения последнего выполнения fmt.Println("Tic a las", t) в зависимости от груза твоего процессора в этом моменте.

Чтобы предотвращать это неосновательное поведение достаточна добавить какие-то военная служба секунды в Sleep для того, чтобы он достаточного времени, три раза печатают Tic что внутри цикла.

Нечто похожее:

package main

import "time"
import "fmt"

func main() {
    ticker := time.NewTicker(time.Millisecond * 500)
    go func() {
        for t := range ticker.C {
            fmt.Println("Tick at", t)
        }
    }()
    time.Sleep(time.Millisecond * 1505)
    ticker.Stop()
    fmt.Println("Ticker detenido")
}

Он мог бы давать тебе фальшивую печать, из которой он не был бы должен переходить так ввиду того, что go он синхронный, но то, за чем оно последует, что, выполнив go func() ты создаешь асинхронную подпрограмму, которая работает наряду с time.Sleep и поэтому дело в том, что целая программа не прекращает функционировать пока главный трэд "сонливый".

1
ответ дан 24.11.2019, 14:36
  • 1
    У меня есть вопрос. и # 191; В Go нет первенства, как он происходит в java? В java, когда ему удается переместить что-то, как это может устанавливаться первенство с setPriority класса Thread и эксперта и # 237; способствовать тому, чтобы некие трэды предпочли на других, когда им удается в то же время попросить ресурс. Я это спрашиваю, потому что этот soluci и # 243; n он делается мне более оптимальным, чем то, что ты комментируешь. В и # 250; n так, если это не существует в Go har и # 233; это увеличивания нескольких миллисекунд в main. Уже я hab и # 237; в отчитанный tambi и # 233; n этого поведения, но я подумал, что в Go hab и # 237; в soluci и # 243; n элегантнее сходный с первенством в java – abrahamhs 14.04.2016, 02:06
  • 2
    @abrahamhs не s и # 233; если существует первенство в Go, но проблема - что не est и # 225; s манипулируя двумя goroutines они, чтобы стараться помещать первенство, est и # 225; s манипулируя главным трэдом ejecuci и # 243; n и одна goroutine. Первенство s и # 243; tendr и # 237; в чувство, если их было два goroutines, хотя не s и # 233; если он существует. – Gepser 14.04.2016, 02:17
  • 3
    Ok, спасибо. har и # 233; с миллисекундами, дело в том, что, когда справляется первенство, если возможно помещать первенство более высокое, чем первенство главного трэда. Но har и # 233; с миллисекундами, мной и #250; nica opci и # 243; n. Привет и спасибо. – abrahamhs 14.04.2016, 02:20
  • 4
    Ничего, и busqu и # 233; но не encontr и # 233; совсем не на первенстве tour.golang.org/concurrency/1 – Gepser 14.04.2016, 02:21
  • 5
    Если, в java у main есть нормальное первенство и трэды, которые ты создаешь, ты можешь помещать ему первенство более высокое или более низкое, чем это. О Go я подумал, что было что-то как это, так как я вижу, что он сочетает темы скопления других языков с новыми и собственными предложениями, и этот combinaci и # 243; n, у которого есть Go, делается мне более элегантным и работоспособным. Этот язык мне кажется тем, кто лучше манипулирует скоплением всех, которые есть на рынке. – abrahamhs 14.04.2016, 02:25

Теги

Похожие вопросы