Сообщение Re: Тестовое задание ... от 13.06.2015 6:04
Изменено 13.06.2015 8:32 DvaSL
Спасибо всем за ответы
Большинство замечаний — о мелочах, которые конечно важны, но не чрезмерно. Почти все они относятся к реализации классов, которые играют роль поставщика тестовых данных и которые я писал без должного внимания, ибо в реальном проекте их просто не будет. Но, согласен, стоило бы и поаккуратней.
Вот что меня несколько удивило:
antropolog писал:
A> если вкратце — то сделано не то что требовалось. От слова совсем. Необходимо было реализовать класс CThreadPool с двумя методами по десять строк каждый, а вышел какой-то франкенштейн, непонятно что делающий. Ещё раз перечитайте задание, внимательно. И сделайте именно то, что требуется.
Нигде в задании нет ни слова о 2х методах по десять строк) Но да бог с ним, я не об этом...
Честное слово, не представляю как можно реализовать ТЗ в 2х десятках строчек.
Для выполнения условия "Не должно быть "повисших" клиентов, даже если клиентов больше, чем потоков. Т.е. поток должен обрабатывать разных клиентов по-очереди, а не одного до завершения всех его задач" придется в любом случае вести список клиентов и на его основе вычислять следующее задание для свободного потока.
Или мсье может предложить алгоритм попроще?
Здравствуйте, gandjustas, Вы писали:
A>1) слишком много классов, реализация размазана по трем классам, очень сложно читать
A>2) лишний поток для раскидывания задач, потоки — дорогое удовольствие.
A>3) отсутствует оповещение об окончании
A>4) из-за 3) неясно как будет освобождаться task
A>5) очередь стоило бы сделать lockfree
1) Сложно? Имо, наоборот, это как раз суть ООП — создавать абстракции и раскидывать их по классам. Если взять класс CThreadPoolX и просмотреть его методы, то становится однозначно понятно, что он делает. Я много раз видел, как люди запихивают все в 1 класс и это кошмар для понимания
2) Согласен, но без него будет подвисать пользователь пула потоков, что навряд ли правильно. Впрочем, тут вопрос производительности
3) Об окончании чего?
4) Не совсем понял о чем речь. Все task обернуты в shared_ptr и корректно освобождаются после удаления их из очередей. Есть, конечно, вариант, что они освободятся на стороне клиента пула потоков, но знаете, это же все таки тестовое задание, а не реальная разработка.
5) Да, пожалуй, Вы правы.
Большинство замечаний — о мелочах, которые конечно важны, но не чрезмерно. Почти все они относятся к реализации классов, которые играют роль поставщика тестовых данных и которые я писал без должного внимания, ибо в реальном проекте их просто не будет. Но, согласен, стоило бы и поаккуратней.
Вот что меня несколько удивило:
antropolog писал:
A> если вкратце — то сделано не то что требовалось. От слова совсем. Необходимо было реализовать класс CThreadPool с двумя методами по десять строк каждый, а вышел какой-то франкенштейн, непонятно что делающий. Ещё раз перечитайте задание, внимательно. И сделайте именно то, что требуется.
Нигде в задании нет ни слова о 2х методах по десять строк) Но да бог с ним, я не об этом...
Честное слово, не представляю как можно реализовать ТЗ в 2х десятках строчек.
Для выполнения условия "Не должно быть "повисших" клиентов, даже если клиентов больше, чем потоков. Т.е. поток должен обрабатывать разных клиентов по-очереди, а не одного до завершения всех его задач" придется в любом случае вести список клиентов и на его основе вычислять следующее задание для свободного потока.
Или мсье может предложить алгоритм попроще?
Здравствуйте, gandjustas, Вы писали:
A>1) слишком много классов, реализация размазана по трем классам, очень сложно читать
A>2) лишний поток для раскидывания задач, потоки — дорогое удовольствие.
A>3) отсутствует оповещение об окончании
A>4) из-за 3) неясно как будет освобождаться task
A>5) очередь стоило бы сделать lockfree
1) Сложно? Имо, наоборот, это как раз суть ООП — создавать абстракции и раскидывать их по классам. Если взять класс CThreadPoolX и просмотреть его методы, то становится однозначно понятно, что он делает. Я много раз видел, как люди запихивают все в 1 класс и это кошмар для понимания
2) Согласен, но без него будет подвисать пользователь пула потоков, что навряд ли правильно. Впрочем, тут вопрос производительности
3) Об окончании чего?
4) Не совсем понял о чем речь. Все task обернуты в shared_ptr и корректно освобождаются после удаления их из очередей. Есть, конечно, вариант, что они освободятся на стороне клиента пула потоков, но знаете, это же все таки тестовое задание, а не реальная разработка.
5) Да, пожалуй, Вы правы.
Re: Тестовое задание ...
Спасибо всем за ответы
Большинство замечаний — о мелочах, которые конечно важны, но не чрезмерно. Почти все они относятся к реализации классов, которые играют роль поставщика тестовых данных и которые я писал без должного внимания, ибо в реальном проекте их просто не будет. Но, согласен, стоило бы и поаккуратней.
Вот что меня несколько удивило:
antropolog писал:
A> если вкратце — то сделано не то что требовалось. От слова совсем. Необходимо было реализовать класс CThreadPool с двумя методами по десять строк каждый, а вышел какой-то франкенштейн, непонятно что делающий. Ещё раз перечитайте задание, внимательно. И сделайте именно то, что требуется.
Нигде в задании нет ни слова о 2х методах по десять строк) Но да бог с ним, я не об этом...
Честное слово, не представляю как можно реализовать ТЗ в 2х десятках строчек.
Для выполнения условия "Не должно быть "повисших" клиентов, даже если клиентов больше, чем потоков. Т.е. поток должен обрабатывать разных клиентов по-очереди, а не одного до завершения всех его задач" придется в любом случае вести список клиентов и на его основе вычислять следующее задание для свободного потока.
Или мсье может предложить алгоритм попроще?
Здравствуйте, gandjustas, Вы писали:
A>1) слишком много классов, реализация размазана по трем классам, очень сложно читать
A>2) лишний поток для раскидывания задач, потоки — дорогое удовольствие.
A>3) отсутствует оповещение об окончании
A>4) из-за 3) неясно как будет освобождаться task
A>5) очередь стоило бы сделать lockfree
1) Сложно? Имо, наоборот, это как раз суть ООП — создавать абстракции и раскидывать их по классам. Если взять класс CThreadPoolX и просмотреть его методы, то становится однозначно понятно, что он делает. Я много раз видел, как люди запихивают все в 1 класс и это кошмар для понимания
2) Согласен, но без него будет подвисать пользователь пула потоков, что навряд ли правильно. Впрочем, тут вопрос производительности
3) Об окончании чего?
4) Не совсем понял о чем речь. Все task обернуты в shared_ptr и корректно освобождаются после удаления их из очередей. Есть, конечно, вариант, что они освободятся на стороне пользователя пула потоков, но знаете, это же все таки тестовое задание, а не реальная разработка.
5) Да, пожалуй, Вы правы.
Большинство замечаний — о мелочах, которые конечно важны, но не чрезмерно. Почти все они относятся к реализации классов, которые играют роль поставщика тестовых данных и которые я писал без должного внимания, ибо в реальном проекте их просто не будет. Но, согласен, стоило бы и поаккуратней.
Вот что меня несколько удивило:
antropolog писал:
A> если вкратце — то сделано не то что требовалось. От слова совсем. Необходимо было реализовать класс CThreadPool с двумя методами по десять строк каждый, а вышел какой-то франкенштейн, непонятно что делающий. Ещё раз перечитайте задание, внимательно. И сделайте именно то, что требуется.
Нигде в задании нет ни слова о 2х методах по десять строк) Но да бог с ним, я не об этом...
Честное слово, не представляю как можно реализовать ТЗ в 2х десятках строчек.
Для выполнения условия "Не должно быть "повисших" клиентов, даже если клиентов больше, чем потоков. Т.е. поток должен обрабатывать разных клиентов по-очереди, а не одного до завершения всех его задач" придется в любом случае вести список клиентов и на его основе вычислять следующее задание для свободного потока.
Или мсье может предложить алгоритм попроще?
Здравствуйте, gandjustas, Вы писали:
A>1) слишком много классов, реализация размазана по трем классам, очень сложно читать
A>2) лишний поток для раскидывания задач, потоки — дорогое удовольствие.
A>3) отсутствует оповещение об окончании
A>4) из-за 3) неясно как будет освобождаться task
A>5) очередь стоило бы сделать lockfree
1) Сложно? Имо, наоборот, это как раз суть ООП — создавать абстракции и раскидывать их по классам. Если взять класс CThreadPoolX и просмотреть его методы, то становится однозначно понятно, что он делает. Я много раз видел, как люди запихивают все в 1 класс и это кошмар для понимания
2) Согласен, но без него будет подвисать пользователь пула потоков, что навряд ли правильно. Впрочем, тут вопрос производительности
3) Об окончании чего?
4) Не совсем понял о чем речь. Все task обернуты в shared_ptr и корректно освобождаются после удаления их из очередей. Есть, конечно, вариант, что они освободятся на стороне пользователя пула потоков, но знаете, это же все таки тестовое задание, а не реальная разработка.
5) Да, пожалуй, Вы правы.