|
|
|
вопрос по потокам
|
|||
|---|---|---|---|
|
#18+
член массиваMasterZivпропущено... Ошибаешься, в таком случае также безусловно нужна синхронизация.Не ошибаюсь. Если элементы являются простыми типами (32-х битное, например), то один поток может менять что хочет и как хочет, при том что другие потоки могут читать эти изменяемые элементы без синхронизации. Если же тип данных сложен и для него не существует атомарной операции для записи изменения в память (тот же double на 32-х битных системах и при размере структуры 8 байт будет записываться в элемент массива за два приема - первые 32 бита, затем вторые), то тут да, читающие потоки могут словить "полуготовое" значение, не являющееся ни старым, ни новым значением элемента, тут обязательно нужно синхронизировать читателей с писателем. атомарность "типа" вроде же не гарантирует а) что все операции над типом будут атомарны б) видимость результата операции для всех потоков в многопроцессорной среде же... Допустим для java хотя бы слово volatile добавить к "переменнной", чтобы приблизиться к решению. авторНадо изменить массив, причём сделать изменения требуется вне зависимости от значений элементов массива (просто добавлять к определённым членам массива определённые извне значения, которые не зависят от массива) Операция добавить - уже зависит от члена массива, так как сначала читает данные из массива, потом пишет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2013, 10:58 |
|
||
|
вопрос по потокам
|
|||
|---|---|---|---|
|
#18+
ayvangoНадо изменить массив, причём сделать изменения требуется вне зависимости от значений элементов массива (просто добавлять к определённым членам массива определённые извне значения, которые не зависят от массива). Надо ли использовать критические секции или что-то ещё или же при таких операциях в этом нет необходимости? 1. Можно пойти по очень простому пути: каждый поток пишет всегда только в свою ячейку массива ;) Почитайте про Ring Buffer - он может натолкнуть вас на решение. 2. Если уже данность, что в 1у ячейку массива могут писать несколько потоков, пойти по наиболее простому пути: -отдельная блокировка на писателей -отдельная блокировка на читатетей по всему массиву 3. Если производительность не позволяет пойти по пути "2", то есть пойти почитать про то, как работает ConcurrentHashMap - там данные сегментированы, и потому блокирует не всю коллекцию, а некий сегмент с элементами(допустим с индексом от 0 до 10). Я думаю стоит начать с простого+покрыть тестами по производительности, чтобы уже идти в сторону сложных алгоритмов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2013, 11:05 |
|
||
|
вопрос по потокам
|
|||
|---|---|---|---|
|
#18+
Озверинчлен массивапропущено... Не ошибаюсь. Если элементы являются простыми типами (32-х битное, например), то один поток может менять что хочет и как хочет, при том что другие потоки могут читать эти изменяемые элементы без синхронизации. Если же тип данных сложен и для него не существует атомарной операции для записи изменения в память (тот же double на 32-х битных системах и при размере структуры 8 байт будет записываться в элемент массива за два приема - первые 32 бита, затем вторые), то тут да, читающие потоки могут словить "полуготовое" значение, не являющееся ни старым, ни новым значением элемента, тут обязательно нужно синхронизировать читателей с писателем. атомарность "типа" вроде же не гарантирует а) что все операции над типом будут атомарны б) видимость результата операции для всех потоков в многопроцессорной среде же... Допустим для java хотя бы слово volatile добавить к "переменнной", чтобы приблизиться к решению. a) атомарных операций только 8: load, store, add, sub, and, or, xor, cas. Первые 7 выполняются, как wait-free. Любые более сложные операции можно реализовать атомарно через cas, как lock-free. б) Гарантия volatile слабее, чем atomic - они оба отменяют переупорядочивание, но только atomic ещё гарантирует атомарность. Видимость же в многопроцессорной среде обеспечивается соответствующими барьерами памяти, тут volatile вообще не в тему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2013, 14:17 |
|
||
|
вопрос по потокам
|
|||
|---|---|---|---|
|
#18+
volatile вообще не в темуб) Гарантия volatile слабее, чем atomic - они оба отменяют переупорядочивание Точнее даже они оба сами по себе не отменяют переупорядочивание, а только отменяют жесткую оптимизацию, которая могла бы совсем выкинуть эти инструкции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2013, 14:24 |
|
||
|
вопрос по потокам
|
|||
|---|---|---|---|
|
#18+
volatile вообще не в темуvolatile вообще не в темуб) Гарантия volatile слабее, чем atomic - они оба отменяют переупорядочивание Точнее даже они оба сами по себе не отменяют переупорядочивание, а только отменяют жесткую оптимизацию, которая могла бы совсем выкинуть эти инструкции. вы сами себе противоречите..видимость как раз в разрезе оптимизации ;) еще раз основной тезис: атомарность абсолютно не снимает проблем видимости(поток кэширует переменную и работает с локальной копией), отсюда volatile . Про переупорядочивание я вообще ничего не писал.я лишь подразумевал, что атомарность а) ничего не решает в данном контексте б) чтобы был намек на решение, надо хотя бы volatile добавить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2013, 16:25 |
|
||
|
вопрос по потокам
|
|||
|---|---|---|---|
|
#18+
Озверинvolatile вообще не в темупропущено... Точнее даже они оба сами по себе не отменяют переупорядочивание, а только отменяют жесткую оптимизацию, которая могла бы совсем выкинуть эти инструкции. вы сами себе противоречите..видимость как раз в разрезе оптимизации ;) еще раз основной тезис: атомарность абсолютно не снимает проблем видимости(поток кэширует переменную и работает с локальной копией), отсюда volatile . Про переупорядочивание я вообще ничего не писал.я лишь подразумевал, что атомарность а) ничего не решает в данном контексте б) чтобы был намек на решение, надо хотя бы volatile добавить. а) Атомарность в контексте языка - это std::atomic, который отменяет жесткую оптимизацию - ему не нужен никакой volatile б) volatile никак не решает проблему видимости между потоками. Проблему видимости решают барьеры std::memory_order. Если метафорично: вы предлагаете пачку с солью(std::atomic) подсолить(volatile), чтобы она стала сладкая(observe modifications). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2013, 16:49 |
|
||
|
вопрос по потокам
|
|||
|---|---|---|---|
|
#18+
volatile вообще не в темуОзверинпропущено... вы сами себе противоречите..видимость как раз в разрезе оптимизации ;) еще раз основной тезис: атомарность абсолютно не снимает проблем видимости(поток кэширует переменную и работает с локальной копией), отсюда volatile . Про переупорядочивание я вообще ничего не писал.я лишь подразумевал, что атомарность а) ничего не решает в данном контексте б) чтобы был намек на решение, надо хотя бы volatile добавить. а) Атомарность в контексте языка - это std::atomic, который отменяет жесткую оптимизацию - ему не нужен никакой volatile б) volatile никак не решает проблему видимости между потоками. Проблему видимости решают барьеры std::memory_order. Если метафорично: вы предлагаете пачку с солью(std::atomic) подсолить(volatile), чтобы она стала сладкая(observe modifications). В разрезе какого языка?:) Тут программирование и как бе атомарными могут быть типы, машинозависимые..вы о чем вообще?)))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2013, 09:44 |
|
||
|
вопрос по потокам
|
|||
|---|---|---|---|
|
#18+
Озверинvolatile вообще не в темупропущено... а) Атомарность в контексте языка - это std::atomic, который отменяет жесткую оптимизацию - ему не нужен никакой volatile б) volatile никак не решает проблему видимости между потоками. Проблему видимости решают барьеры std::memory_order. Если метафорично: вы предлагаете пачку с солью(std::atomic) подсолить(volatile), чтобы она стала сладкая(observe modifications). В разрезе какого языка?:) Тут программирование и как бе атомарными могут быть типы, машинозависимые..вы о чем вообще?)))) О том что типы не могут быть атомарными, т.к. если нет выравнивания то никакой атомарности ни для каких типов не будет. Кроме 1-байтных, т.к. тут всегда есть выравнивание. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2013, 12:26 |
|
||
|
вопрос по потокам
|
|||
|---|---|---|---|
|
#18+
самодельный логгер. сишарп Код: c# 1. 2. 3. 4. 5. 6. 7. несколько ниток пишут в один и тот-же логгер // используется очередь одна читает из очереди и выводит в файл. в функции, которая пишет в логгер, надо блокировать все переменные (1) или достаточно блокировать собственно только запись в очередь и не вносить локальные переменные метода в блокировку (2)? 1 версия Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 2 версия Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2013, 00:00 |
|
||
|
|

start [/forum/topic.php?fid=16&gotonew=1&tid=1341734]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
394ms |
get topic data: |
7ms |
get first new msg: |
4ms |
get forum data: |
1ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 689ms |

| 0 / 0 |
