Класс библиотеки C #: требуется многопоточность?

#c# #multithreading

#c# #многопоточность

Вопрос:

Я разрабатываю библиотечный класс, который использует последовательный порт для связи со схемой управления. Если установлено больше датчиков, то для отправки строки ответа схеме требуется больше времени. Например, если установлен только один датчик, я должен подождать 100 мс перед чтением входного буфера, но если установлено 6 датчиков, я должен подождать 100 мс 6 * 20 мс. Для некоторых функций (если подключено максимальное количество датчиков) Возможно, мне придется подождать до 9 секунд, прежде чем контроллер отправит строку ответа.

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

Спасибо!

1. Как выглядит эта библиотека? Есть ли у него только один метод для считывания входных данных с датчиков? Возможно ли вообще выполнить эту задачу параллельно? Другими словами, может ли схема выполнять 2 задачи одновременно?

2. 9 секунд — это, по сути, навсегда, а 100 мс — чертовски долго (примерно максимальное время, которое люди не воспринимают как «ожидание»). Я бы использовал только асинхронные методы, чтобы препятствовать блокировке (что, конечно, все еще можно сделать).

Ответ №1:

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

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

1. Я согласен с @StrangeWill. Класс не должен использовать многопоточность, если вы не готовы вызывать события выполнения и реализовать метод Abort() . Поскольку ваши внешние устройства все равно будут отправлять свои данные обратно, Abort() будет затруднен. Держите свой класс однопоточным и позвольте вызывающей стороне решить, хотят ли они использовать его асинхронно или в отдельном потоке. Тем не менее, вы можете рассмотреть возможность включения примеров каждого подхода с вашим классом в его документацию.

Ответ №2:

Это вопрос дизайна. Если вы разрабатываете библиотеку, вы выбираете решение. Если ваш босс или кто-то другой определил контракт, вы делаете это так, как он / она хочет.

Я бы реализовал оба, то есть базовый класс для простых сценариев с одним датчиком и что-то вроде многопоточного класса-оболочки для случаев, когда пользователь хочет использовать больше датчиков с фоновыми потоками.