Програмиране с Go

Курс във Факултета по Математика и Информатика към СУ

Втора задача

  1. Публикувахме втората задача за домашно. Условието и примерен тест може да намерите и в github хранилището ни. Може да ви е полезно да си припомните нещата от този гайд преди да предадете решението.

    Тук можете да ни питате ако има нещо неясно по условието.

  2. Един може би не особено умен въпрос - не трябва ли функцията да има вида  func ConcurrentRetryExecutor(tasks []func() string, concurrentLimit int, retryLimit int) <-chan struct{index int; result string} - ";" вместо "," в описанието на структурата?

  4. Добавил съм пояснение в задачата че очакваме ConccurrentRetryExecutor да върне резултатния канал без да изчаква първо да завършат всички(или която и да) задачи. Затварянето на канала служи за да се каже че задачите са били завършени.

  5. Аз имам следния въпрос:

    Ако върнатият string е празен, това се приема за грешка и трябва веднага да изпълните отново задачата.

    Съответно в примера задачите се изпълняват на 2 нишки и по дефолт на 1 логически процесор, което ги прави конкурентни. Според цитираната част от условието се предполага, че фейлнала задача трябва да се изпълни отново. Това аз го разбирам като:

    Starting concurrent executor!
Task 2 successfully returned 'second'
Task 3 returned an error!
Task 3 returned an error!
Task 3 returned an error!
Task 1 successfully returned 'first'
Task 4 successfully returned 'am I last?'
All done!

    Което преполага, че в момента, в който задача 3 е фейлнала, то програмата се опитва да я изпълни наново без да дава приоритет на друга нишка.

    Та.. въпросът ми е, грешно ли предполагам? Ако да, защо?

  6. @Георги Горанов :

    1. Конкурентноста няма общо с изпълнението има общо с начина по който е написан кода - тоест дали е написан така че да може да бъдат изпълнявани независимо.
    2. от реда results := ConcurrentRetryExecutor(tasks, 2, 3) става ясно че се иска да се изпълняват по не повече от 2 задачи конкурентно с 3 опити за успешно изпълнение
    3. Предполагам че под нишки имаш предвид горотини при което положение по скоро е минимум е 2 - за да може двете задачи да се изпълняват конкурентно, но по скоро поне 3 за да може в третата да се чете резултата.
    4. Логическите процесори по подразбиране са колкото имаш а на колко ще бъдат изпълнение и на колко нишки на ОС-а ще бъде разпределена вътрешно програмата няма отношение, не е едно и ще говорим за това по подробно нататък.
    5. Когато задача три се провали тя се изпълнява отново, но конкурентно с нея искаме да се изпълнява още една (защото сме казали по 2 задачи конкурентно) и стига да има останали това трябва да се случва.
    6. Предполагам че заблудата ти идва от даването на приоритет на друга горотина, което е работа на runtime-а на go и ще говори по подробно по нататък за това кога може да се случи. Ще спомена че time.Sleep има добри шансове да де приоритета на друга горотина.

    Извинявай за забавения отговор, надявам се да съм ти помогнал, ако не питай пак ;)

  7. Ако съм разбрал правилно, в примерната задача трябва да има 1 независима го рутина за четене (която връща канала) и още 2 го рутини (от retryLimit), които да изпълняват задачите.

    Също така ако една задача фейлне, предполага ли се да се направи нова рутина за всеки нов опит за изпълнение или тя трябва да продължи в същата рутина (от условието аз разбирам, че тя трябва да продължи в същата рутина)?

  9. @Пламен Калчев Не съм сигурен как точно ползваш wait groups. но ако е за да изчакаш до приключването на всички горотини и чак тогава да затвориш канала, това не е точно по условие. Ти искаш да върнеш канала веднага като ти потрябва без да блокираш. Нз колко ми е уместен коментара. Peace.. <3

    От докумeнтацията:

    A WaitGroup waits for a collection of goroutines to finish. The main goroutine calls Add to set the number of goroutines to wait for. Then each of the goroutines runs and calls Done when finished. At the same time, Wait can be used to block until all goroutines have finished.

  11. Мене ме бъгва върнатия резултат и как можем да правим гаранция за последователността, в която се случват нещата за теста. Ние палим len(task) go ротини и не можем да кажем със сигурност коя от тях ще увеличи брояча на семефора и ще се изпълни преди останалите.

  13. @Пламен - да, задачата се решава лесно без ползването на материал който не сме преподавали и препоръчваме да се опитвате да използвате само нещата които сме преподали

    @Георги Горанов - нямам намерение да ви задължаваме колко горотини трябва да ползвате, но да това което си казал е количество горутини, които биха довели до вярно решение ако бъде написано правилно. Дали в същата или в нова горутина е въпрос на имплементация - тоест може и двете, стига да се повтаря докато не успее и не повече от retryLimit-a и разбира се без друга задача да заема нейното място преди да завърши.

  16. Какво трябва да бъде поведението при retryLimit равен на 0?

    Трябва ли да бъде същото като при retryLimit равно на 1?

    Какво трябва да прави програмата при concurrentLimit равен на 0 или обещавате да не го подавате?

  18. Хей! Здравейте! :)

    Аз имам едно малко предложение:

    Защо не направим така, че тестовете ни да се пускат, когато предаваме кода си?

    Често ми се случва да предам кода, но да не знам точно какви неща трябва да се тестват за него, или заданието да не е безкрайно изчистено за ъгловите случай или детайли поведенчески. От тази гледна точка ще е добре, да можем да видим как се справяме с тестовете, за да знаем дали сме разбрали правилно задачата.

    Винаги е приятно да получим коментари и от Вас, разбира се.

    Поздрави! :) Щастлив и вълнуващ ден на всички!

Трябва да сте влезли в системата, за да може да отговаряте на теми.