Дошли у меня руки до менеджера потоков, который может защищать данные при доступе из разных потоков, но возник вопрос -- синхронный с рабочим потоком доступ успешно защищается (onExec), нужно ли защищать доступ, синхронный с главным потоком (onSyncEcec)

------------ Дoбавленo:


А че, никому не интересно
Будем и дальше ловить глюки с мультипоточностью в плане совместного доступа к данным

------------ Дoбавленo:


К черту менеджер, вот что получилось. Жду критику и предложения по усовершенствованию
------------ Дoбавленo:

А почему, кстати, даже штатный поток отвратительно ведет себя из-под FPC

Просто не все сталкивались с проблемами потоков и просто с потоками

Пример работает нормально. Тк с потоками проблем у меня небыло то и протестировать я его не могу...

согласен.
Для меня вообще например вопрос:
о какой многопоточности можно говорить при одном процессоре.
всё равно одно тормозит другое.

nesco, а зачем потоки защищать?

Вячеслав, http://www.realcoding.net/article/view/101

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

Вот, интересна будет новая версия -- 2.00. Тут потки выполняют некоторые действия в режиме ожидания, что бы не простаивать впустую

Я как раз про это.
То есть вся поточность виртуальна.

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

Вот это интерестно.
Но только если бы сам комп этим занимался.
Например для проверки компа на вирусы надо запустить сам антивирус.
А он сильно тормозит систему.
Вот бы он сам проверял пока комп незанят,и занимал бы 1% проца когда занят.
Но к сожалению не всё так гладко так как помимо проца он занимает ещё и HDD
память и так далее.
Так вот твоя программа созданная многопоточной могла бы работать так как этого
хочется только при условии что у неё будет собственный HDD .
А в реале сколько, я ни пробовал запускать программы работающие в фоновом режиме
постоянно, все они когда нибудь заметно тормозят комп.
Я конечно согласен что пока идёт отрисовка можно и цикл выполнить но где гарантия что пока
идёт отрисовка цикл успеет закончится.
Вот смотрю сейчас
загрузка проца 2-4%
процессов 43(уже)
И твои ещё прибавятся итого 45
пускай загрузка проца будет 10%
Так откуда же появляются периодические тормоза.
Да просто HDD - то они используют один.
Вообщем кто мне покажет загрузку HDD

Компонент нужный, но пример, извини, - черт ногу сломает + ни одного коментария... и что там паралельно выполняется - мигание светодиодов ?
------------ Дoбавленo:

Нарисуй, если не в лом, движение точки по диагонали, чтобы один For выдавал X, а другой паралельно Y
У меня не получается

светодиод

nesco, если можно на пальцах - чем оно лучше (или будет лучше?) чем сегодняшняя реализация, с учётом того, что защиту от совместного доступа Dilma тоже где-то показывал..
------------ Дoбавленo:

многоядерность пока побарабану?

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

------------ Дoбавленo:



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

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

nesco, выбросил из твоего примера все три MutExThread. Хаб прекрасно справляется с их работой. Единственное - светодиоды не моргают, но если это очень нужно, то можно организовать (на "штатных компонентах")
В HiAsm нет возможности запустить одновременно (от одного Event) несколько потоков - только через Hub который и определяет очередность. А может есть ?
------------ Дoбавленo:

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

А по какому критерию определять что можно пустить в поток ,а что нет