Тупик .... Компилятор Builder 6.0 Win Xp пишу маленький сервачек.... На серверсокете........




При создании формы.....

Такой код не работает..... Выскакивают мессадж боксы..... Поидеи потоки по одному должны зайти..... Но счетчики меняються в
CritsectQweryBuffer... Посмотрел отладчиком может я заработался...
    

Заранее спасибо.

Это сообщение отредактировал(а) GremlinProg - 13.6.2012, 07:01

Должно работать, давайте весь код

Кода несколько страниц(20), сейчас просто написал маленький код и такая же ошибка........



Еще прикрепляю проект... Конекчусь телнетом выскакивает два мессадж бокса.....
Два раза коннекчусь.....

С уважением .. Заранее спасибо...

Присоединённый файл ( Кол-во скачиваний: 3 )
 CRITICAL_SECTION.rar 352,62 Kb

Рискну предположить, что ServerSocket1Accept синхронизируется с главным потоком, а потому EnterCriticalSection будет выполняться много раз.

Что то я вас не понял...... В критическую секцию должен заходить один поток........ Мессадж бокса два!!!!!!! Значит туда попали два потока........ При нормальной работе другие ожидают....... 

Все просто код работает правильно


После MessageBox ты покидаешь критическую секцию так как MessageBox(NULL, ....);  не блокирует поток.

Пишу вот так.... 
Пока не нажму первый мессадж второй не выскакиват, значит блокирует.......
Блокирует MB_OK  вот в чем ответ.......

Это сообщение отредактировал(а) GremlinProg - 13.6.2012, 07:04

И правда странная хрень

У меня есть подозрение, что InitializeCriticalSection(&CritsectQweryBuffer); выполняется неоднократно... 
Нельзя ли это вывести за пределы TForm1?

Может что то не то в настройках проекта, но ставил релиз..... Такая же байда.....  
ServerSocket1 интересно как работает?????
Пробовал вставить в форм шоу инициализацию.....

И как это синхронизировать.???????



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

Такое ощущение что связано это с оконной процедурой.........

Заранее спасибо, с уважением.

Добавлено @ 13:47

Один раз выполняеться, посмотрел отладчиком......

Добавлено @ 13:56

Скорее всего так и получаеться синхронизация походу есть..... Но прицем тут критическая секция?????? Взрыв мозга.......        

Скорее еще прикол в свойствах ServerSocket1..........
Может тему в сети перенести ???? Может там что посоветуют???? 

Это сообщение отредактировал(а) bass - 11.6.2012, 13:59

В смысле при втором подключении будет снова InitializeCriticalSection.

Нет ставлю брейк, запускаю приложение, останавливаеться......
Далее произвожу коннекты не разу на брайке не останавливаеться.....

Так не корректно, нужно пользоваться Interlocked-функциями...

Это просто чтоб понять что происходит....... А происходит следующие приложение виснет, заначит процедура ServerSocket1Accept синхронизирована с главным потоком, как предположил  Alexeis........
А вот куда ковырять пока не соображу........

вот ответ


если проще, то если критическая секция была уже вызвана в потоке,  то при повторном вхождении в нее в этом же потоке не происходит блокировки

Это сообщение отредактировал(а) Dem_max - 11.6.2012, 14:21

Поток один и тот же............. 
Dem_max 200 %...............

Получаеться ServerSocket1 не создает поток на новое подключение.........

И как выкручиваться в данной ситуации...?????       

И интересно сколько тогда может выдержать подключений ServerSocket1 ?????????

Как вариант не парится
Так как ServerSocket1Accept(); работает в одном потоке, не делай долгих задержек в этой функции. Т. е.  если надо добавляй новый сокет в список и выходи из функции, только же опять не забывай добавлять через критические секции, так как в где то в другом потоке список может использоваться.

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

Доступ к лейблу и визуальным компонентам должен быть только из главного потока.
http://rxlib.ru/WinLesson/bles2_1.htm

Полностью согласен с тобой(там операции были несложные, поэтому забил, знаю сделал не по програмерски... Ну...), но как быть допустим в этой ситуации........... Поток то у нас один теперь как выяснилось.......

И в одном моменте сбиваеться последовательность ситуаций и вылетает ошибка....... Для этого и продумывал критическую секцию.....
Век живи век учись..... 

С уважением.....

Это сообщение отредактировал(а) bass - 11.6.2012, 15:34

  Я имел ввиду, что обработчик вызывается в главном потоке. Т.е. поток сокета синхронизируется с главным и вызывает обработчик в главном потоке. Но тут я тоже протупил, потому как если обработчик вызывается в главном, то пока он не закончил свое выполнение не сможет синхронизироваться второй обработчик, ведь один поток не может исполнять 2 действия одновременно.

Добавлено через 6 минут и 58 секунд
Хотя не, теоретически может, если использует механизм асинхронных вызовов Windows.
Представим себе ситуацию.
1) 1й поток получил accept и записался в очередь к главному потоку на синхронизацию
2) Вызвался обрабочик в главном потоке и вызвался месажбокс
3) Месажбокс заблокировался на обработке сообщений
4) 2й поток получился accept и записался в очередь к главному потоку на синхронизацию
5) Поскольку месажбокс занимается обработкой сообщений, то это разрешает вызов 2го обработчика от 2го потока.
6) Вызывается второй обработчик также в главном потоке, и для него критическая секция не является блокировкой поскольку вызывающий поток 1.

Все понял................ 

Как и предположил что связанно с оконной процедурой. Вернее с ее свойствами приема потока сообщений оказалось.   А как быть в такой ситуации.....

  Отключить синхронизацию с главным потоком ServerType = stNonBlocking

В его свойствах и так стоит ServerType = stNonBlocking ...................
Так и стоит.....

bass, а если поставить блокирующий? Возможно он все неблокирующий обрабатывает в главном потоке. Кстати! Он же может события accept ставить на обработку окном главного потока! Это и есть наиболее вероятный способ разблокировки сокета. Значит нужно переключить в блокирующий.

Все заработался пришла в голову мысль поставить счетчик потоков зашедших если больше одного то выскакивает мессадж бокс....... Когда поток уходит смотрит на наличие мессадж боксов и тыкает мышкой......))))))))))))))))))))))))))

А серьезно..... Щас ставим блокирующий........ Куча клиенов выполняют опперации и тут мы попадаем в эту функцю  и блокируемся секунд на 5 все....... А так все работаем кому в друг понядобилась эта функция встаем в очередь....... Там еще есть запрос пользователя..... И тогда сервер зависнет............

Но всеравно попробую.........


Неа не получилось......


Form1->Memo1->Lines->Add(IntToStr( GetCurrentThreadId()));
EnterCriticalSection(&CritsectQweryBuffer);
MessageBox(NULL,"", "", MB_OK );
LeaveCriticalSection(&CritsectQweryBuffer);

Конектиться клиент выскакивает мессадж бокс........ Конектиться другой и в мемо не отображаеться номер потока.... Закрываю мессадж появлеться .... Значит блокиреться все работа.... Хоть коннект и проходит......


Это сообщение отредактировал(а) bass - 11.6.2012, 18:25

Почитай тут
http://forum.vingrad.ru/topic-60076.html
приглянись к семафорам, они вроде как блокируют вход.

Замените CRITICALSECTION на Mutex'ы - они будут блокироваться даже если их позовут в одном потоке

Иногда да такого маленького ответа приходиться столько докапываться......
Ступил и пошел разбираться почему не срабатывает ......... 
Спасибки всем...... Если мутексы блокируються то тогда вопрос решен.....

Это сообщение отредактировал(а) bass - 11.6.2012, 19:38

  Это еще почему? Насколько я знаю мьютексы под виндой ведут себя точно также как и критические секции. Чтобы добиться полного исключения я использовал эвенты. А у мьютексов фича такая. Раз 1 поток то безопасно вызывать и они не блокируют повторный вход.

Кажеться так и получилось, пока руки не добираються до этого кода но быстро накалякал  Mutex'ы кажеться такая же байда....
Щас посмотрю......

Да, действительно -
посыпаю голову пеплом   
Тогда действительно только семафор со счетчиком 1 ( http://msdn.microsoft.com/en-us/library/wi...v=vs.85%29.aspx )

Так ребят я вообще не чего не пойму........ 


Когда запускаю потоки с кнопки два не одного месадж бокса не высвечиваеться а когда запускаю сервер через WaitForSingleObject(mut,INFINITE); проскакивает...... Бред.........    

Я же тебе сказал посмотри на семафоры.

Спасибо но ответа было два и я как всегда выбрал неверный..... Ну это то что осталось доделать в сервачке...... И как всегда закон подлости...... 

Вот это номер................. Заходит один поток вешаеться на мессадж боксе, заходит другой и виснет весь сервер................. Вот  и синхронизировал................)))))))))))))) Говорил тыкать мышкой в месадж боксы эффективнее....)))))))))))
Так а че делать то ???????................. Не ожидал такого прикола, хотя выше уже такой тест приводился ......., я не обратил внимания......
Семафоры действительно заработали.......
Если честно я думал  что ServerSocket создает поток для каждого подключения......... А оказалось............

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

Да оставьте все как было в начале, небольшоая добавочка только:

Если не ошибась должно помочь...

MessageBox(NULL,"", "", MB_OK | MB_TASKMODAL );

Мессадж боксы использовались в роли тестов.......................................................

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

Ну так и форму сделайте модальной.

Откуда там взяться 2м потокам, если все вызовы ServerSocket1Accept сериализуются в один и тот же поток (сами же экспериментально на эти грабли только что наступили)? Если вы в ServerSocket1Accept  не будете показывать модальные окна и вызывать MessageBox'ы, то одновременный вызов нескольких экземпляров ServerSocket1Accept в принципе невозможен

Оставляй как было в самом первом коде и не парься

Убрал критические секции ......
Поставил MB_TASKMODAL..... И вообще не чего не изминилось..... Скорее всего в этом дело MB_OK....... Поидеи модальная форма должна появиться и управление обратно отдаться так ведь????

Сделаю так запущу еще один поток, ему какойто сокет запрос на создание буфера, поток закончил передал буфер сокету........ Если два сокета сделали запрос, в порятке очереди......... Думаю так заработает....... И все ок будет................ 

Оставляй как было в самом первом коде и не парься.....
Вылетают ошибки.......

Я же вам уже писал - дело в MesageBox. Уберите его, и все будет исполняться строго последовательно и без всяких CRITICALSECTION, Mutex'ов и всего прочего.

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

Точно? Это надо у ТС уточнить. Если да, тогда можно оставить, но в любом случае вызовы самого ServerSocket1Accept никогда не могут наложиться друг на друга (если только вы их сами не наложите)

точно

Да действительно вы правы, сейчас только протестировал....... Поставил слип на 10 минут....... И этот слиип парализовал работу серввера.......     Сделал отдельный поток который занимаеться обработкой долгих операций и выполняющий запрос пользователя............
Все заработало УРА!!!!!!!

Всем огромное человеческое спасибо........ Ставлю на тесты...... 

А вот интересно сколько выдержит подключний ServerSocket...... Сейчас больше 10 врятли будет..... Но на будущее...????
Ну если его на сервер поставить естественно........

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

Но могу сказать если сделать запрос пользователя, и повесить сервер и продолжать подключения виснет вся система.....(((((

Ой, что то вы суровое напрограмировали   Что бы из User Space подвесить систему надо очень сильно постараться   

Ну не совсем..... Виснет рабочий стол и прога..... Можно запустить таск манеджер и убить процес......  Но это в тесте с месадж боксами.....
ХР.....)))))))))

возможно использует главный поток всей программы.

Грабли грабли и еще раз грабли............... Вот глупые люди всегда наступают на одни и теже грабли.... Но умные не лучше всегда наступат на новые.......   
Незнаю к какому типу себя отнести, но на очередные наступил......


 


Или 0.0.0.0 выдает либо 30.4.121.0 или что то подобное.......... Хотя коннект провожу с 127.0.0.1 ..................




Вот такая вещь работает..... Остаеться одно..... Socket->Handle..... либо там не стоит 4 ех байтовое выравнивание либо он не привязан к настояшему хендлу сокета....... И еще почитав про ServerSocket ....... Оказалось что после коннекта Index может меняться...... И такой код будет глючить........... Индекс я назначаю при коннекте, вернее получаю....... А вся привязка клиента идет по его хендлу.....


Код в топку............ Где то валялся клиент написанный на винапи переделаю под сервер конект на бинд надо сменить и все....... 
Не когда в жизни больше не возму ServerSocket..............



Это сообщение отредактировал(а) feodorv - 16.6.2012, 17:15