когда вызывается garbage collector

[Ilia Kandrashou]

Прочитал что горутины переключаются между собой в строго определённые моменты. одним из таких ментов является срабатывание GC!

Так вот вопрос когда же срабатывает GC и соответственно процесс может переключится на другую горутину ?

Что бы мне как разработчику действительно не надо было заботится о локах ресурсов, я должен чётко знать все возможные места перключения горутин.

Вообще сама идея сопрограмм подразумевает, что разработчик имеет полный контроль над тем когда переключится в другой "поток" и именно поэтому может не заботиться о совместном доступе к ресурсам. 

В golange этого контроля в явном виде вроде бы нет, и с неявным вопросы.

[Vladimir]

Порядок выбора горутин при переключении не определен стандартом и может меняться без уведомления. Заботиться о правильном совместном доступе к ресурсам всё так же необходимо.

17 июня 2014 г., 21:11 пользователь Ilia Kandrashou <loo...@gmail.com> написал:

--
Вы получили это сообщение, поскольку подписаны на группу "Golang Russian".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес golang-ru+...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Aln Kapa]

Есть пакет http://golang.org/pkg/sync

17 июня 2014 г., 18:27 пользователь Vladimir <de...@mechmind.net> написал:

[Aln Kapa]

Есть пакет http://golang.org/pkg/sync

Вы можете "имеет полный контроль над тем когда переключится в другой "поток""

[Alexey Palazhchenko]

Привет,

> Вообще сама идея сопрограмм подразумевает, что разработчик имеет полный контроль над тем когда переключится в другой «поток"

Слово «горутина» для того и ввели, чтобы не нести багаж идей, которые не совсем применимы.

–-–
Алексей «AlekSi» Палажченко

[Dmitry Vyukov]

Это не сопрограммы, горутины выполняются параллельно, поэтому о
синхронизации надо заботиться независимо от переключения.

[Ilia Kandrashou]

Я на самом деле просто хочу узнать когда срабатывает GC? 

может ли он срабатывать где то в середине функции, например, при выделении очередного массива, и тем самым преключить процесс в другую горутину ?

[Игорь Хазиев]

http://dave.cheney.net/2014/06/07/five-things-that-make-go-fast

Places where Goroutines may yield to others are:

• Channel send and receive operations, if those operations would block.
• The Go statement, although there is no guarantee that new goroutine will be scheduled immediately.
• Blocking syscalls like file and network operations.
• After being stopped for a garbage collection cycle.
• 
  

17 июня 2014 г., 20:29 пользователь Ilia Kandrashou <loo...@gmail.com> написал:

Я на самом деле просто хочу узнать когда срабатывает GC? 

может ли он срабатывать где то в середине функции, например, при выделении очередного массива, и тем самым преключить процесс в другую горутину ?

[Вячеслав Бахмутов]

А ещё вам нужно начать следить за вызовами функций и даже аллокациями в памяти..

вторник, 17 июня 2014 г., 18:11:10 UTC+4 пользователь Ilia Kandrashou написал:

[Ilia Kandrashou]

как раз из за этого списка а точнее из за "After being stopped for a garbage collection cycle" и возник мой вопрос!

И я пытаюсь выяснить когда же этот "being stopped " может произойти!

Наверно вопрос можно свести к следующему

Запускает ли scheduller цикл сборщика, или сборщик сам запускает schedule ?

вторник, 17 июня 2014 г., 19:32:38 UTC+3 пользователь Igor Khaziev написал:

[Игорь Хазиев]

17 июня 2014 г., 19:55 пользователь 'Dmitry Vyukov' via Golang Russian <gola...@googlegroups.com> написал:

2014-06-17 7:11 GMT-07:00 Ilia Kandrashou <loo...@gmail.com>:

Это не сопрограммы, горутины выполняются параллельно, поэтому о

синхронизации надо заботиться независимо от переключения.

Как они могут выполнятся параллельно? А если процесс будет запущен на одном, одноядерном процессоре?

Здесь http://dave.cheney.net/2014/06/07/five-things-that-make-go-fast написано, что 

Goroutines are cooperatively scheduled, rather than relying on the kernel to manage their time sharing.

Я так до конца и не понял, как это перевести. 

[Ilia Kandrashou]

не уходим в офтоп.. :)

логически подумав - в какой-то горутине при выделении очередного массива процесс может обнаружить что память закончилась ->  и запустить сборщик, -> а тот по завершению своей работы, вернёт управление в другую горутину !

прав ли я ?

вторник, 17 июня 2014 г., 19:48:45 UTC+3 пользователь Igor Khaziev написал:

[Игорь Хазиев]

17 июня 2014 г., 20:54 пользователь Ilia Kandrashou <loo...@gmail.com> написал:

не уходим в офтоп.. :)

логически подумав - в какой-то горутине при выделении очередного массива процесс может обнаружить что память закончилась ->  и запустить сборщик, -> а тот по завершению своей работы, вернёт управление в другую горутину !

прав ли я ?

Не знаю прав ли ты, но я согласен с твоим мнением. 

[Ilia Kandrashou]

тогда получим проблему совместного доступа к ресурсам. 

Если первая горутина начинает менять состояния каких-то объектов, и рассчитывает что их никто не будет трогать пока она не закончит. А тут GC перключает процесс в другую горутину, которая как раз "трогает" эти не завершённые объекты. Получаем катастрофу.

Всё таки может кто нибудь даст хоть ссылку где почитать в каких местах может срабатывать GC в golang ?

вторник, 17 июня 2014 г., 19:58:28 UTC+3 пользователь Igor Khaziev написал:

[Dmitry Vyukov]

В данный момент (Go1.2, Go1.3) GC может прерывать горутины только в
начале функции. В середине функции горутины не могут быть прерваны.

[Morozov Alexandr]

Вам надо в любом случае ставить лок в том или ином виде. Проблема совместного доступа всегда на ваших плечах. Даже без вызова GC горутина может переключиться при вызове функции.

[Ilia Kandrashou]

что значит в начале функции ? вы имеете ввиду что GC может сработать при вызове какой либо функции (при условии что она не оптимизировалась в inline) ?

Вообще конечно моменты переключения горутин весьма не явны, особенно для начинающих gophers. Это делает горутины гораздо ближе к потокам чем к корутинам. В моих глазах это минус, т.к. по опыту, программирования в стиле корутин удобнее чем в стиле потоков, но возможно я просто плохо понимаю парадигму CSP.

вторник, 17 июня 2014 г., 20:13:42 UTC+3 пользователь Dmitry Vyukov написал:

[Ilia Kandrashou]

там вроде функции должны отвечать определённым условиям что бы сработал scheduler. и это отдельная тема от GC. где то читал про это вскользь, не могу найти, может подскажете ссылку ?

вторник, 17 июня 2014 г., 20:17:12 UTC+3 пользователь Morozov Alexandr написал:

[Dmitry Vyukov]

2014-06-17 16:13 GMT-07:00 Ilia Kandrashou <loo...@gmail.com>:
> что значит в начале функции ? вы имеете ввиду что GC может сработать при
> вызове какой либо функции (при условии что она не оптимизировалась в inline)
> ?

GC вызывается либо явно (c помощью runtime.GC) или при аллокации
памяти. Когда GC вызывается, он начинает останавливать горутины
выполняющиеся на других потоках. Эта остановка может произойти в
начале любой (не заинлайненой) функции.

> Вообще конечно моменты переключения горутин весьма не явны, особенно для
> начинающих gophers. Это делает горутины гораздо ближе к потокам чем к
> корутинам. В моих глазах это минус, т.к. по опыту, программирования в стиле
> корутин удобнее чем в стиле потоков, но возможно я просто плохо понимаю
> парадигму CSP.

Горутины это и есть потоки. Не надо пытаться программировать их как
корутины. Надо программировать их как обычные потоки, и не думать о
возможных точках переключения.

[Dmitry Vyukov]

Планировщик останавливает горутину есть она выполняется более 10 мс.
Эта остановка так же происходит в начале любой функции.

[Vladimir]

Ещё, gc может вызываться в моменты, когда все горутины заблокированы (в ожидании завершения IO etc), верно? Тем самым не занимая полезное время выполнения.

18 июня 2014 г., 10:26 пользователь 'Dmitry Vyukov' via Golang Russian <gola...@googlegroups.com> написал:

[Dmitry Vyukov]

2014-06-17 20:34 GMT-07:00 Vladimir <de...@mechmind.net>:
> Ещё, gc может вызываться в моменты, когда все горутины заблокированы (в
> ожидании завершения IO etc), верно? Тем самым не занимая полезное время
> выполнения.

Да. И так же когда горутина заблокирована на канале или мьютексе,
прервана планировщиком, прервана runtime.Gosched или еще не начала
выполняться.
Остановка касается только выполняющихся в данный момент горутин.

> 18 июня 2014 г., 10:26 пользователь 'Dmitry Vyukov' via Golang Russian
> <gola...@googlegroups.com> написал:
>
>> Планировщик останавливает горутину есть она выполняется более 10 мс.
>> Эта остановка так же происходит в начале любой функции.
>

[Vladimir]

А в случае горутины, которая в цикле занимается неблокирующей работой без вызовов функций (много-много перемножений матриц, например), планировщик и/или не сможет остановить её? И это предотвратит работу gc? 

18 июня 2014 г., 10:40 пользователь 'Dmitry Vyukov' via Golang Russian <gola...@googlegroups.com> написал:

Настройки подписки и доставки писем: https://groups.google.com/d/optout.

[Dmitry Vyukov]

Да, на данный момент это так

[Ilia Kandrashou]

среда, 18 июня 2014 г., 6:25:46 UTC+3 пользователь Dmitry Vyukov написал:

2014-06-17 16:13 GMT-07:00 Ilia Kandrashou <loo...@gmail.com>:
> что значит в начале функции ? вы имеете ввиду что GC может сработать при
> вызове какой либо функции (при условии что она не оптимизировалась в inline)
> ?

GC вызывается либо явно (c помощью runtime.GC) или при аллокации
памяти. Когда GC вызывается, он начинает останавливать горутины
выполняющиеся на других потоках. Эта остановка может произойти в
начале любой (не заинлайненой) функции.


> Вообще конечно моменты переключения горутин весьма не явны, особенно для
> начинающих gophers. Это делает горутины гораздо ближе к потокам чем к
> корутинам. В моих глазах это минус, т.к. по опыту, программирования в стиле
> корутин удобнее чем в стиле потоков, но возможно я просто плохо понимаю
> парадигму CSP.

Горутины это и есть потоки. Не надо пытаться программировать их как
корутины. Надо программировать их как обычные потоки, и не думать о
возможных точках переключения.

ВОТ! в этом вся суть! многие документы ссылаются на GO как на язык с реализацией корутин (таже вики http://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0 ), а при разборе оказалось, что это не так. Думаю для многих это не очевидно, как было и для меня.

[Dmitry Vyukov]

где в вики написано про корутины в го?

[Ilia Kandrashou]

быстро сработали.

С утра ссылка на Go была на это странице. можете посмотреть в истории редактирования (если не вы редактировали) , исправлено после того как я запостил тут ссылку.

Но таких упоминаний я встречаю не только в вики. Можно организовать отдельную тему, по мере обнаружения буду скидывать туда ссылки, но что это даст, все ресурсы ведь не поправите ?

суббота, 21 июня 2014 г., 17:39:20 UTC+3 пользователь Dmitry Vyukov написал:

[John Khvatov]

On 21 Jun 2014, at 19:23, Ilia Kandrashou <loo...@gmail.com> wrote:

быстро сработали.

С утра ссылка на Go была на это странице.

Ага, было: http://ru.wikipedia.org/w/index.php?title=Сопрограмма&diff=63759094&oldid=63442381

-- 

WBR, John Khvatov

[Ilia Kandrashou]

вот кстати, на самой странице про GO http://ru.wikipedia.org/wiki/Go ссылка на сопрограммы

" .. слова go, которое запускает анонимную или именованную функцию в заново созданной go-процедуре (аналог сопрограмм). "

суббота, 21 июня 2014 г., 18:23:47 UTC+3 пользователь Ilia Kandrashou написал:

[Ilia Kandrashou]

и англоязычной версии ещё есть http://en.wikipedia.org/wiki/Coroutine ))

[Sergey Shepelev]

> многие документы ссылаются на GO как на язык с реализацией корутин

Вы же наверняка знаете поговорку про надпись на заборе.

Релевантен один документ: http://golang.org/ref/spec

Это -- спецификация, этот документ разработчики языка поддерживают в актуальном состоянии. Кажется, что это непродуктивно -- искать другие документы, в которых кто-то пересказывает своими словами, возможно, даже не имея опыта с Go. Конечно, в пересказах будет множество неточностей или домыслов.