|
|
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
no56892 DEVcoach , Кстати, Вы выдвигали версию о том, что это можно объяснить якобы "кэширванием в регистрах", дак вот, попробуйте затестить Ваш же пример с 17 переменными (целочисленных регистров AMD64 - 16).Ну напишите :-) А смысл этих мытарств в чем? Может это регистры, может JIT закэшировал значение в стэке, и не трогает хип. Может быть еще что-то. Прикладной ценности эти копания не имеют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 15:15 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
DEVcoachВо-вторых, есть масса других способ заставить этот поток увидеть s=1. Например, как уже приводили выше пример, с помощью Thread.yield(). Как вы объясните, что видимость появляется в этом случае? Это нативный метод, к synchronization action не относится ... а видимость дает? Не только yield, но и со sleep. Хотя jls 17.9 Sleep and Yield ... It is important to note that neither Thread.sleep nor Thread.yield have any synchronization semantics. In particular, the compiler does not have to flush writes cached in registers out to shared memory before a call to Thread.sleep or Thread.yield, nor does the compiler have to reload values cached in registers after a call to Thread.sleep or Thread.yield. ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 15:35 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
For AllВообще-то мгопоточность программировали ещё на 8086 процессоре (даже не 80186 и тем более задолго до появления 80286). CAS-операций в 8086 как известно нет. Как же они делали это?Насколько я помню, префикс lock был изначально. Более следующие процессоры просто ограничили его использование. Плюс, Intel изначально реализовала "блокировку прерываний" для команд, меняющих SP. Именно для того, чтобы гарантировать атомарное переключение стека. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 18:53 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovFor AllВообще-то мгопоточность программировали ещё на 8086 процессоре (даже не 80186 и тем более задолго до появления 80286). CAS-операций в 8086 как известно нет. Как же они делали это?Насколько я помню, префикс lock был изначально. Более следующие процессоры просто ограничили его использование. Плюс, Intel изначально реализовала "блокировку прерываний" для команд, меняющих SP. Именно для того, чтобы гарантировать атомарное переключение стека. Насколько я помню, на 8086 многопоточность делали без использования "блокировки прерываний". Тем не менее работало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 19:20 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
For AllНасколько я помню, на 8086 многопоточность делали без использования "блокировки прерываний"Это вы так думаете. Системный таймер (мегагерц с копейками поделённый на 64к) мог тикнуть в любое времяТем не менее работало.Оно потому и работало, что национальные особенности записи в SP обеспечивали беспроблемное переключение стека, а lock гарантировал работу семафоров. Если, конечно, они использовались. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 19:29 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
забыл ник В этот раз соглашусь со свеномом, многопоточность сложная тема, и именно в деталях и терминах кроется дьявол. Так как примногопоточном программировании ошибку допустить проще простого, как раз таки понимание этих деталей и рулит. Не буду утверждать что я сам гуру, но множество приведенных вами неточностей позволяет сделать вывод про уровень ваших знаний, да, я бы взял вас в команду писать код, который просто работает в разных потоках, но я бы не взял вас в команду по написанию чего-то нового и нешаблонного(пока что). Вообще многопоточность такая штука, в которой просто необходима практика, практика и еще раз практика, а лучше всего пяток пофикшенных гейзенбагов :) Именно так - практика! И как раз практики-то с многопоточностью у меня нет, и именно поэтому забылись детали теории (неиспользуемые знания забываются). Таки куда приходить собеседоваться на позицию "писать код, который просто работает" ? )) Удалёнку рассматриваете? Я как раз сейчас в поиске работы.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 21:29 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovFor AllНасколько я помню, на 8086 многопоточность делали без использования "блокировки прерываний"Это вы так думаете. Системный таймер (мегагерц с копейками поделённый на 64к) мог тикнуть в любое времяИ он тикал - прерывания же не блокировались. И клавиатура тикала по нажатию клавиши, и последовательные порты. Вообще все прерывания срабатывали.Basil A. SidorovТем не менее работало.Оно потому и работало, что национальные особенности записи в SP обеспечивали беспроблемное переключение стека, а lock гарантировал работу семафоров. Если, конечно, они использовались.lock - это блокировка шины на время выполнения команды, актуальна для многопроцессорных/многоядерных систем, и к реализации семафоров на процессоре 8086 (который не яляется многоядерным) не имеет никакого отношения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2014, 11:57 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
For AllBasil A. Sidorovпропущено... Это вы так думаете. Системный таймер (мегагерц с копейками поделённый на 64к) мог тикнуть в любое времяИ он тикал - прерывания же не блокировались. И клавиатура тикала по нажатию клавиши, и последовательные порты. Вообще все прерывания срабатывали.Basil A. Sidorovпропущено... Оно потому и работало, что национальные особенности записи в SP обеспечивали беспроблемное переключение стека, а lock гарантировал работу семафоров. Если, конечно, они использовались.lock - это блокировка шины на время выполнения команды, актуальна для многопроцессорных/многоядерных систем, и к реализации семафоров на процессоре 8086 (который не яляется многоядерным) не имеет никакого отношения. А что за lock? Разве одной команды? Я всегда думал, что именно чтобы несколько команд выполнить, так сказать транзакцию. А смысл что-то я непойму: на "электрическом уровне" тот-же "mov <something>, 0xadress" implicitly лочит шину или как? А по поводу while(sharedobject.field == 0) { ... } я засабмитил баг в оракл, это ИМХО явный баг. Посмотрим результаты... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2014, 13:37 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
no56892А что за lock? Разве одной команды? Я всегда думал, что именно чтобы несколько команд выполнить, так сказать транзакцию. А смысл что-то я непойму: на "электрическом уровне" тот-же "mov <something>, 0xadress" implicitly лочит шину или как? lock - Assert LOCK# signal for the next instruction. The LOCK prefix causes the LOCK# signal to be asserted during execution of the instruction that follows it. И ещё по поводу шины. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2014, 13:46 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
For Allno56892А что за lock? Разве одной команды? Я всегда думал, что именно чтобы несколько команд выполнить, так сказать транзакцию. А смысл что-то я непойму: на "электрическом уровне" тот-же "mov <something>, 0xadress" implicitly лочит шину или как? lock - Assert LOCK# signal for the next instruction. The LOCK prefix causes the LOCK# signal to be asserted during execution of the instruction that follows it. И ещё по поводу шины. Это если одна шина на память и на IO устройства, а какой смысл в lock если сейчас в в процессоре как минимум одна шина на память и одна на IO ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2014, 13:56 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
no56892А что за lock? Разве одной команды? Я всегда думал, что именно чтобы несколько команд выполнить, так сказать транзакцию. А смысл что-то я непойму: на "электрическом уровне" тот-же "mov <something>, 0xadress" implicitly лочит шину или как?no56892Это если одна шина на память и на IO устройства, а какой смысл в lock если сейчас в в процессоре как минимум одна шина на память и одна на IO ? Например, команда add <something>, 0xadress с точки зрения шины не атомарна - там несколько общений к шине идёт. В многопроцессорной/многоядерной системе разные процессоры/ядра запросто могут обратиться в одну и ту же ячейку памяти (по одной и тоже шине на память) и поломать add друг-другу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2014, 14:10 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
For Allno56892А что за lock? Разве одной команды? Я всегда думал, что именно чтобы несколько команд выполнить, так сказать транзакцию. А смысл что-то я непойму: на "электрическом уровне" тот-же "mov <something>, 0xadress" implicitly лочит шину или как?no56892Это если одна шина на память и на IO устройства, а какой смысл в lock если сейчас в в процессоре как минимум одна шина на память и одна на IO ? Например, команда add <something>, 0xadress с точки зрения шины не атомарна - там несколько общений к шине идёт. В многопроцессорной/многоядерной системе разные процессоры/ядра запросто могут обратиться в одну и ту же ячейку памяти (по одной и тоже шине на память) и поломать add друг-другу. А, понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2014, 14:43 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
забыл никне совсем, multithreading он же возможен и на одном ядре. Это способ разбить задачу на юниты, которые могут, но не обязаны выполняться параллельно. Concurrency же рассматривает как раз вопросы параллельного выполнения, и возникающие в связи с этим сложности, видимость, целостность, и тд В общем-то конкурентные программы могут работать в одном потоке, т.к. конкурентность часто обеспечивается "софтово" -- виртуальной машиной или рантаймом языка и не зависит от потоков/процессов ОС (но может их использовать). Собственно вот. Так что по сути разница между multithreading и concurrency только в реализации, а параллельные вычисления -- совсем другая тема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2014, 17:05 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
For Alllock - это блокировка шины на время выполнения команды, актуальна для многопроцессорных/многоядерных систем, и к реализации семафоров на процессоре 8086 (который не яляется многоядерным) не имеет никакого отношения.Мопвашуять ... Вы постоянно игнорируете периферийное железо, которое сидело той же самой (общей) шине. Не процессором единым ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2014, 18:57 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
DEVcoach Сказать, что volatile не кэшируются, хотя они кэшируются; Можно отсюда поподробнее ? Что происходит в тот момент, когда я пытаюсь считать волатильную перменную ? У меня в каждом потоке свое закешированное значение волатильной переменной(непосредственно перед чтением), как они синхронизируются? Как выбирается самое актуальное значение? P.S. я знаю, что volatile write happens-before volatile read ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 11:45 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
redwhite90Что происходит в тот момент, когда я пытаюсь считать волатильную перменную ? У меня в каждом потоке свое закешированное значение волатильной переменной(непосредственно перед чтением), как они синхронизируются? Как выбирается самое актуальное значение? P.S. я знаю, что volatile write happens-before volatile read Грубо говоря на пальцах это так: переменная - это значение в памяти. Кэш это регистр процессора. Обычную переменную можно не читать из памяти (долго), а прочитать из регистра (быстро). Чтение volatile переменной происходит из памяти. Поэтому там актуальное значение, а не из регистра, где может быть устаревшее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 11:56 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, спасибо. Получается, что при каждом изменении волатильной переменной она записывается в локальный кеш потока и в память. P.S. Значит всё-таки "суперкопия" существует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 12:02 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, ну и возникает вопрос, зачем вообще тогда кэшировать волатильные переменные? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 12:04 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
redwhite90Blazkowicz, ну и возникает вопрос, зачем вообще тогда кэшировать волатильные переменные? Зависит от алгоритма. Можешь кешировать. И ты получишь ретроспективноее ее представление. Твой алгоритм будет быстр - но синхронен с "точкой времени в прошлом". По аналогии с курсорами версионных СУБД. Ты не получаешь объективные данные. А ты получаешь данные на момент когда открылся курсор (у тебя - начался твой АЛГОРИТМ). Короче это algorithm depends. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 12:09 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
maytonredwhite90Blazkowicz, ну и возникает вопрос, зачем вообще тогда кэшировать волатильные переменные? Зависит от алгоритма. Можешь кешировать. И ты получишь ретроспективноее ее представление. Твой алгоритм будет быстр - но синхронен с "точкой времени в прошлом". По аналогии с курсорами версионных СУБД. Ты не получаешь объективные данные. А ты получаешь данные на момент когда открылся курсор (у тебя - начался твой АЛГОРИТМ). Короче это algorithm depends. в java я же не могу получить неактуальное значение волатильной переменой. И соответственно алгоритм свой написать не могу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 12:23 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
redwhite90в java я же не могу получить неактуальное значение волатильной переменой. И соответственно алгоритм свой написать не могу. Поэтому в Java, чтобы не изучать арихитектуру каждого CPU и особенности JIT компиляции под него, сделана единая JMM, на которую нужно ориентироваться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 12:25 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, я наверное непонятно задаю вопрос. Что поменялось бы если бы волатильная переменная не кешировалась бы? Есть хоть один кейс, когда используется значение волатильной переменной из кеша? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 12:27 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
redwhite90Что поменялось бы если бы волатильная переменная не кешировалась бы? Есть хоть один кейс, когда используется значение волатильной переменной из кеша? С точки зрения Java - разницы никакой нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 12:31 |
|
||
|
Concurrency Vs multithreading
|
|||
|---|---|---|---|
|
#18+
redwhite90maytonпропущено... Зависит от алгоритма. Можешь кешировать. И ты получишь ретроспективноее ее представление. Твой алгоритм будет быстр - но синхронен с "точкой времени в прошлом". По аналогии с курсорами версионных СУБД. Ты не получаешь объективные данные. А ты получаешь данные на момент когда открылся курсор (у тебя - начался твой АЛГОРИТМ). Короче это algorithm depends. в java я же не могу получить неактуальное значение волатильной переменой. И соответственно алгоритм свой написать не могу. Давай на конкретном случае. Если волатальная переменная - это статистический счётчик который ты просто сыплешь в лог или кидаешь в интерфейсы мониторинга - это одно дело. Если она - это аргумент алгоритма - то тебе придётся "сбрасывать" алгоритм и каждый раз заново выполнять перерасчёт чтобы обеспечить актуальность. Отсюда вопрос. Зачем вообще нужна эта "грязная" (dirty) волатальная перменная. Может лучше переписать код и организовать events которые будут запускать другие потоки с актуальными аргументами? Может с другой стороны подойти к синхронизации? Может volatile это вовсе не тот философский камень который тебе нужен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 12:31 |
|
||
|
|
start [/forum/topic.php?fid=59&msg=38616879&tid=2126936]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
144ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 208ms |
| total: | 417ms |
| 0 / 0 |
