Здравствуйте, Serginio1, Вы писали:

S>>>·>Какие конкретно камни ты имеешь в виду и как они обходятся в c#?
S>·>ИЧСХ, ответа не последовало.
S> Я тебе уже приводил статью, там все расписано.
Т.е. статью ты не осилил, на простой вопрос ответить не можешь. ЧТД.

S>>>В том, что бы перенести старый код. Только и всего.
S>·>Т.е. самоцель. Ценность переписывания кода — перенести старый код. Круто, чё. Хобби у тебя, видимо, такое: переписывание кода из пустого в порожнее.
S> Не самоцель, а необходимость переноса старого кода, для увеличения производительности серверов.
Откуда эта необходимость возникла, и как от неё можно избавиться?

S>·>Ок, т.е. ты соглашаешься, что код с потоками проще. Надеюсь, ты получил ответ на свой вопрос.
S> Я соглашаюсь, что он проще, но и примитивнее. Бейсик тоже простой, только вот много на нем не сделаешь.
Что конкретно у тебя не получается?

S>Многие тоже по началу воротили нос от задач с async/await
И сейчас воротят. См. сабж.

S>С Задачами у тебя намного больше свободы. Кроме того есть прекрасная вещь как TaskCompletionSource c которым ты сам можешь контролировать задачу.
Аналог CompletableFuture, похоже.

S>Пример
S>AsyncProducerConsumerCollection

S>public class AsyncProducerConsumerCollection<T>
Опасная структура. Она должна быть bounded size для создания back pressure, иначе всё навернётся в самый неподходящий момент. Вот только добавить maxSize ты уже вряд ли осилишь.

S>Используя эту структуру данных, можно написать код, например следующий:
Тут ведь как... Можно написать, но можно и не писать! Меньше кода — лучше.

S>Кроме того и от блокировок можно избавляться
Так ведь можно и не избавляться!

S>

S>// БЫЛО
S>// СТАЛО
S>

Было мало кода, был простой код. Стало много сложного кода. Что ты хотел мне этим продемострировать?