Комментарии 38
Снаряд не может ждать, пока отрисуется танчик, танк не может ждать пока рисуется стена, чтобы пошевелится.
… а у вас рисовалка умеет много потоков?
1-й поток (мэйн) — должен отправлять нажатую клавишу на сервер.
2-й поток должен принимать координаты танков.
3-й координаты стен.
4-й координаты снарядов.
А почему выделенные потоки, а не событийная модель?
Небольшое описание потоков: любой поток создаётся через пространство System.Threading.
А почему не тредпул? Почему не таски с cooperative cancellation?
1. Зачем вам класс Thread? Используйте Task. И почитайте про асинхронность. Судя по вашему методу мейн, если при открытии конзоли вы не нажмете клавишу, то мы понапрасну будем есть очень много ресурсов.
2. Не знаю в какие дебри вы залезли с http, но его использовать будет гораздо проще(потому что это текстовый протокол, а не бинарный коим являеться tcp). Особенно если вы планируете веб приложение, вам надо делать ставку на http.
3. Было бы не плохо выложить ссылку на репозиторий с кодом. В таком соятоянии, я вообще не вижу кода на расте, а по c# вам надо прочитать style guide. Именование методов с подчеркиванием разве что в WinForms я и видел, которые уже устарели.
Наша новая задача звучит так: создать структуру
public struct player_coor { public static
Вот только у вас не структура, а пространство имен для бедных. Структура, в которой все поля статические — это боль, а не структура. И в многопоточности вы об нее убъетесь. И use вам низачем не нужен, понятное дело.
А вообще, C# — объектно-ориентированный язык, какая религия вам помешала объекты использовать?
пробуют, а не принимают решения.
Ну то есть теоретически, конечно, важно указать на ошибки, но практически опыта чтобы вообще эти ошибки понять ещё нет (я, конечно, могу ошибаться).
Да, я ещё не опытный программист, но стараюсь им стать и именно поэтому выложила эту статью. Где ещё можно услышать критику и советы, кроме как хабра и киберфорума?
(если есть ресурсы — дайте пожалуйста, буду очень благодарна за развитие моей грамотности)
А вы просите объяснения почему сделано так, а не иначе. На этом этапе пробуют, а не принимают решения.
Вопросы "почему так сделано" очень полезны как раз, они заставляют задуматься. Если взято произвольное первое попавшееся решение (как здесь с потоками), то лучше вернуться на шаг назад.
Зачем, зачем у вас внутри async-методов await Task.Run?
class Program
{
public async void MyMethodAsync()
{
Console.WriteLine("Метод MyMethodAsync - до запуска задачи");
await Task.Run(
() =>
{
Console.WriteLine("Метод MyMethodAsync - задача запущена.");
for (int i = 0; i < 50;)
Console.WriteLine("Мы все дружно ждём [" + i++.ToString() + "] раз от потока Асинхронности");
Console.WriteLine("Метод MyMethodAsync - завершение выполнения задачи");
});
Console.WriteLine("Метод MyMethodAsync - выполнение задачи завершено");
}
static void Main(string[] args)
{
Program mc = new Program();
Console.WriteLine("Метод Main - до запуска задачи");
mc.MyMethodAsync();
Console.WriteLine("Метод Main - после запуска задачи");
for (int i = 0; i < 50;)
Console.WriteLine("Мы все дружно ждём ["+i++.ToString()+"] раз от потока Main");
Console.ReadKey();
}
}
Дал такой результат:
На его основе я думаю, что смогу принимать данные из веб-сокета независимо от ввода клавиши из потока мэйн, если я не права: поправьте, буду благодарна!
… а теперь уберите await перед Task.Run. Что изменится? Правильно, одна строчка в консоли, и эта строчка не имеет никакого отношения к выполняемой задаче. После этого со спокойной душой можно переделывать MyMethodAsync из async void в просто void, и наблюдать, что тоже ничего не меняется.
В вашем случае вся конкурентность обеспечена Task.Run, и в этом смысле он ничем не отличается от ThreadPool.QueueUserWorkitem. Ровно то же самое можно написать на чистых тредах с явным управлением, и опять ничего не изменится.
Так зачем вам нужна эта пара async-await, если вы ей вообще не пользуетесь?
Предложите свой вариант, я буду очень признательна.
Для тех кто минусует, прочтите: habrahabr.ru/post/109345
Главное что стоит помнить — надо рисковать!
Без риска я не увидела бы ошибок и не пообщалась бы с таким количеством добрых людей) Спасибо вам, ближе к пятнице будет новая статья (надеюсь что и сервер успею дописать, суммарное кол-во строк кода сейчас 700 и все их придётся разобрать (будет очень больно голове обьяснять))
С# легкий для изучения язык и вы не знакомы с дженерикамм, делегатами, TPL, пишите в процедурном стиле. Я два года рытаюсь писать и чем дальше, тем больше вопросов, а ещё ведь он обновляется. А комментарии очень конструктивны, особенно по соккетам.
Да, я понимаю что эта тактика очень и очень плоха, но именно это и подталкивает новичков на каких-либо ошибках лезть в оф. документацию и узнавать что-то новое.
И да, без ошибок не бывает годных проектов, поэтому я и выкладываю сюда, чтобы услышать конструктив.
Танчики в консоли, статья первая: «От спора к написанию кода»