[Delphi] Многопоточность

@WestSide072 · Регистрация: 15.07.2010

Студворк — интернет-сервис помощи студентам

Интерисует след. вопрос:
"Как сделать создание потоков? (кол-во зависит от того сколько укажет пользователь)"

Хотелось бы увидеть "готовый код", лазя по гуглу оч много информации, но там слишком много лишнего текста читая который тупо мозг взрывается ))

Добавлено через 4 минуты
+ как сделать синхронизацию (Первый пост редактировать не могу, проблемы в опере...)

Добавлено через 19 часов 3 минуты
Есть следующие строчки

Delphi
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
  TNewThread = class(TThread)
  private
  protected
    procedure Execute; override;
  public
    constructor Create(CreateSuspended: Boolean);
  end;
 
constructor TNewThread.Create(CreateSuspended: Boolean);
begin
  inherited Create(CreateSuspended);
end;
 
 
procedure TNewThread.Execute;
begin
 
end;
 
 
 TNewThread.Create(false);

Если последнюю строчку я зациклю циклом for у меня будут создаваться новые потоки? или будет циклиться один?

@yoshimidzo · 15.12.2013, 14:14

Сообщение от FIL

В данном случае надо использовать метод Synchronize, а не семафоры.
И подсчет кол-ва потоков так правильно работать не будет.

подсчет работает, и кажется корректно видно как по завершении потока счетчик уменьшается до нуля либо сам (не осталось строк), либо по моей команде (cb_work)

Добавлено через 1 час 46 минут
в Synchronize пока вникать не стал. создал несколько критических секций. для пробы мне пойдет. с базой данных работает корректно

@kannibal · 30.08.2015, 00:31

Извиняюсь, вопрос может быть не в тему
Я пытаюсь сделать клиент и сервер на сокетах
Сервер принимает команды,
Клиент №1 отправляет,например, команду регистрации
Клиент №2 отправляет, например, команду логиниться
....
И когда клиентов много,я смотрю, что приходит в сокет...
бывает проскакивает такое что команды суммируются в одну команду
И следовательно сервер не понимает, что за команда пришла
Это мне надо делать сервер многопоточным?

@FIL · 30.08.2015, 11:44

Сокеты ничего не знают о твоих командах.
Они тупо передают данные по своему внутреннему алгоритму.
Поэтому в полученной посылке может быть все, что угодно: полкоманды, команда, полторы команды и т.д.
Соответственно, парсинг всего этого дела ложится полностью на плечи программиста.

@kannibal · 30.08.2015, 17:26

Я это прекрасно понимаю!
Вопрос не в этом. Вопрос в том что сокет сервера принимает не одну команду, а сразу две
У меня команда регистрации идет reg#
Следом идет команда логина login#
Но бывает что в сокет попадает одна строка и выглядит так
reg#login#

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

Добавлено через 2 минуты
Может клиенты просто отправляют в одну и ту же секунду команды?
Поэтому команды суммируются в одну на сервере

@FIL · 30.08.2015, 21:11

Сообщение от kannibal

Я это прекрасно понимаю!

Если понимаешь, то чего продолжаешь повторять те же самые вопросы, на которые я ответил постом выше?

@KMSNasgool · 31.08.2015, 07:48

Твой клиент отправил на сервер данные (в твоем случае стоку 'reg#'), не дождавшись ответа от сервера снова шлет ему данные. Между этими акциями проходит менее 1 мс. Соответственно сервер читает из сокета обе строки как одну.
Это не программная ошибка, а ошибка в разработке прикладного протокола.
Разработай для начала правила, по которым у тебя будут общаться сервер и клиент.
Сервер всегда должен отвечать клиенту. Клиент не должен слать на сервер ничего, пока не получит ответ на предыдущий запрос.
Например:
Клиент серверу: reg#
Сервер клиенту: ok#
Клиент серверу: fuck#
Сервер клиенту: cmdnotfound#

Ну и многопоточность тут совсем не причем =)

@Argey · 11.09.2015, 13:22

А почему бы просто не использовать

Delphi
1
synchronize

Так же намного проще будет чем тулить семафоры?

@kannibal · 27.10.2015, 00:19

KMSNasgool, пробовал и так, как Вы пишите. Не получается.
С сервера отправляю ок#имя_клиента#
но на сервер опять проскакивают строки reg#reg#

Новые блоги и статьи Все статьи Все блоги /
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .	сукцессия 24. Промежуточное общее описание модели anaschu 12.07.2026 Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .	сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры. anaschu 12.07.2026 Что реально нашли и починили за эти 5 часов Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .	сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато anaschu 11.07.2026 Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .

@kannibal 0 / 0 / 0 Регистрация: 19.08.2015 Сообщений: 22
	30.08.2015, 00:31
	Извиняюсь, вопрос может быть не в тему Я пытаюсь сделать клиент и сервер на сокетах Сервер принимает команды, Клиент №1 отправляет,например, команду регистрации Клиент №2 отправляет, например, команду логиниться .... И когда клиентов много,я смотрю, что приходит в сокет... бывает проскакивает такое что команды суммируются в одну команду И следовательно сервер не понимает, что за команда пришла Это мне надо делать сервер многопоточным? 0

@FIL Модератор 3492 / 2614 / 742 Регистрация: 19.09.2012 Сообщений: 7,977
	30.08.2015, 11:44
	Сокеты ничего не знают о твоих командах. Они тупо передают данные по своему внутреннему алгоритму. Поэтому в полученной посылке может быть все, что угодно: полкоманды, команда, полторы команды и т.д. Соответственно, парсинг всего этого дела ложится полностью на плечи программиста. 0

@kannibal 0 / 0 / 0 Регистрация: 19.08.2015 Сообщений: 22
	30.08.2015, 17:26
	Я это прекрасно понимаю! Вопрос не в этом. Вопрос в том что сокет сервера принимает не одну команду, а сразу две У меня команда регистрации идет reg# Следом идет команда логина login# Но бывает что в сокет попадает одна строка и выглядит так reg#login# Может у кого есть какие идеи, как с этим бороться? Или кто то сталкивался с такой же проблемой? Добавлено через 2 минуты Может клиенты просто отправляют в одну и ту же секунду команды? Поэтому команды суммируются в одну на сервере 0

@KMSNasgool 61 / 51 / 25 Регистрация: 17.12.2013 Сообщений: 258
	31.08.2015, 07:48
	Твой клиент отправил на сервер данные (в твоем случае стоку 'reg#'), не дождавшись ответа от сервера снова шлет ему данные. Между этими акциями проходит менее 1 мс. Соответственно сервер читает из сокета обе строки как одну. Это не программная ошибка, а ошибка в разработке прикладного протокола. Разработай для начала правила, по которым у тебя будут общаться сервер и клиент. Сервер всегда должен отвечать клиенту. Клиент не должен слать на сервер ничего, пока не получит ответ на предыдущий запрос. Например: Клиент серверу: reg# Сервер клиенту: ok# Клиент серверу: fuck# Сервер клиенту: cmdnotfound# Ну и многопоточность тут совсем не причем =) 0

@kannibal 0 / 0 / 0 Регистрация: 19.08.2015 Сообщений: 22
	27.10.2015, 00:19
	KMSNasgool, пробовал и так, как Вы пишите. Не получается. С сервера отправляю ок#имя_клиента# но на сервер опять проскакивают строки reg#reg# 0