ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Программирование [игнор отключен] [закрыт для гостей] / вопрос по потокам
9 сообщений из 34, страница 2 из 2
  2  все
вопрос по потокам
    #38328944
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
член массиваMasterZivпропущено...
Ошибаешься, в таком случае также безусловно нужна синхронизация.Не ошибаюсь. Если элементы являются простыми типами (32-х битное, например), то один поток может менять что хочет и как хочет, при том что другие потоки могут читать эти изменяемые элементы без синхронизации. Если же тип данных сложен и для него не существует атомарной операции для записи изменения в память (тот же double на 32-х битных системах и при размере структуры 8 байт будет записываться в элемент массива за два приема - первые 32 бита, затем вторые), то тут да, читающие потоки могут словить "полуготовое" значение, не являющееся ни старым, ни новым значением элемента, тут обязательно нужно синхронизировать читателей с писателем.

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

Допустим для java хотя бы слово volatile добавить к "переменнной", чтобы приблизиться к решению.

авторНадо изменить массив, причём сделать изменения требуется вне зависимости от значений элементов массива (просто добавлять к определённым членам массива определённые извне значения, которые не зависят от массива)

Операция добавить - уже зависит от члена массива, так как сначала читает данные из массива, потом пишет.
...
Рейтинг: 0 / 0
12.07.2013, 10:58
| Ответить | Цитировать | Написать  
вопрос по потокам
    #38328967
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
ayvangoНадо изменить массив, причём сделать изменения требуется вне зависимости от значений элементов массива (просто добавлять к определённым членам массива определённые извне значения, которые не зависят от массива). Надо ли использовать критические секции или что-то ещё или же при таких операциях в этом нет необходимости?

1. Можно пойти по очень простому пути: каждый поток пишет всегда только в свою ячейку массива ;) Почитайте про Ring Buffer - он может натолкнуть вас на решение.
2. Если уже данность, что в 1у ячейку массива могут писать несколько потоков, пойти по наиболее простому пути:
-отдельная блокировка на писателей
-отдельная блокировка на читатетей
по всему массиву
3. Если производительность не позволяет пойти по пути "2", то есть пойти почитать про то, как работает ConcurrentHashMap - там данные сегментированы, и потому блокирует не всю коллекцию, а некий сегмент с элементами(допустим с индексом от 0 до 10).


Я думаю стоит начать с простого+покрыть тестами по производительности, чтобы уже идти в сторону сложных алгоритмов.
...
Рейтинг: 0 / 0
12.07.2013, 11:05
| Ответить | Цитировать | Написать  
вопрос по потокам
    #38330250
volatile вообще не в тему
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
volatile вообще не в тему
Гость
Озверинчлен массивапропущено...
Не ошибаюсь. Если элементы являются простыми типами (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 вообще не в тему.
...
Рейтинг: 0 / 0
13.07.2013, 14:17
| Ответить | Цитировать | Написать  
вопрос по потокам
    #38330251
volatile вообще не в тему
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
volatile вообще не в тему
Гость
volatile вообще не в темуб) Гарантия volatile слабее, чем atomic - они оба отменяют переупорядочивание
Точнее даже они оба сами по себе не отменяют переупорядочивание, а только отменяют жесткую оптимизацию, которая могла бы совсем выкинуть эти инструкции.
...
Рейтинг: 0 / 0
13.07.2013, 14:24
| Ответить | Цитировать | Написать  
вопрос по потокам
    #38330578
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
volatile вообще не в темуvolatile вообще не в темуб) Гарантия volatile слабее, чем atomic - они оба отменяют переупорядочивание
Точнее даже они оба сами по себе не отменяют переупорядочивание, а только отменяют жесткую оптимизацию, которая могла бы совсем выкинуть эти инструкции.

вы сами себе противоречите..видимость как раз в разрезе оптимизации ;)
еще раз основной тезис: атомарность абсолютно не снимает проблем видимости(поток кэширует переменную и работает с локальной копией), отсюда volatile . Про переупорядочивание я вообще ничего не писал.я лишь подразумевал, что атомарность
а) ничего не решает в данном контексте
б) чтобы был намек на решение, надо хотя бы volatile добавить.
...
Рейтинг: 0 / 0
14.07.2013, 16:25
| Ответить | Цитировать | Написать  
вопрос по потокам
    #38330583
volatile вообще не в тему
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
volatile вообще не в тему
Гость
Озверинvolatile вообще не в темупропущено...

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

вы сами себе противоречите..видимость как раз в разрезе оптимизации ;)
еще раз основной тезис: атомарность абсолютно не снимает проблем видимости(поток кэширует переменную и работает с локальной копией), отсюда volatile . Про переупорядочивание я вообще ничего не писал.я лишь подразумевал, что атомарность
а) ничего не решает в данном контексте
б) чтобы был намек на решение, надо хотя бы volatile добавить.
а) Атомарность в контексте языка - это std::atomic, который отменяет жесткую оптимизацию - ему не нужен никакой volatile
б) volatile никак не решает проблему видимости между потоками. Проблему видимости решают барьеры std::memory_order.

Если метафорично: вы предлагаете пачку с солью(std::atomic) подсолить(volatile), чтобы она стала сладкая(observe modifications).
...
Рейтинг: 0 / 0
14.07.2013, 16:49
| Ответить | Цитировать | Написать  
вопрос по потокам
    #38332248
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
volatile вообще не в темуОзверинпропущено...


вы сами себе противоречите..видимость как раз в разрезе оптимизации ;)
еще раз основной тезис: атомарность абсолютно не снимает проблем видимости(поток кэширует переменную и работает с локальной копией), отсюда volatile . Про переупорядочивание я вообще ничего не писал.я лишь подразумевал, что атомарность
а) ничего не решает в данном контексте
б) чтобы был намек на решение, надо хотя бы volatile добавить.
а) Атомарность в контексте языка - это std::atomic, который отменяет жесткую оптимизацию - ему не нужен никакой volatile
б) volatile никак не решает проблему видимости между потоками. Проблему видимости решают барьеры std::memory_order.

Если метафорично: вы предлагаете пачку с солью(std::atomic) подсолить(volatile), чтобы она стала сладкая(observe modifications).

В разрезе какого языка?:) Тут программирование и как бе атомарными могут быть типы, машинозависимые..вы о чем вообще?))))
...
Рейтинг: 0 / 0
16.07.2013, 09:44
| Ответить | Цитировать | Написать  
вопрос по потокам
    #38332531
volatile вообще не в тему
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
volatile вообще не в тему
Гость
Озверинvolatile вообще не в темупропущено...

а) Атомарность в контексте языка - это std::atomic, который отменяет жесткую оптимизацию - ему не нужен никакой volatile
б) volatile никак не решает проблему видимости между потоками. Проблему видимости решают барьеры std::memory_order.

Если метафорично: вы предлагаете пачку с солью(std::atomic) подсолить(volatile), чтобы она стала сладкая(observe modifications).

В разрезе какого языка?:) Тут программирование и как бе атомарными могут быть типы, машинозависимые..вы о чем вообще?))))
О том что типы не могут быть атомарными, т.к. если нет выравнивания то никакой атомарности ни для каких типов не будет. Кроме 1-байтных, т.к. тут всегда есть выравнивание.
...
Рейтинг: 0 / 0
16.07.2013, 12:26
| Ответить | Цитировать | Написать  
вопрос по потокам
    #38341475
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
самодельный логгер. сишарп

Код: c#
1.
2.
3.
4.
5.
6.
7.
    public class Logger:IDisposable
    {
        public Queue StringQueue = new Queue();
        MsgLevel ILevel;
        bool Working = false;

.....



несколько ниток пишут в один и тот-же логгер // используется очередь
одна читает из очереди и выводит в файл.

в функции, которая пишет в логгер, надо блокировать все переменные (1) или достаточно блокировать собственно только запись в очередь и не вносить локальные переменные метода в блокировку (2)?

1 версия

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
       public void WriteLine(MsgLevel Importance, String Format, params object[] pars)
        {
            if (Working && Importance >= this.ILevel)
            {
                lock(this) {
                  String Date = "[" + DateTime.Now.ToString()+ "] ";
                  String Message = Date + String.Format("[{0}]\t", Importance) +"\t"+ string.Format(Format, pars);
                  StringQueue.Enqueue(Message);
                }
            }
        }



2 версия

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
       public void WriteLine(MsgLevel Importance, String Format, params object[] pars)
        {
            if (Working && Importance >= this.ILevel)
            {

                  String Date = "[" + DateTime.Now.ToString()+ "] ";
                  String Message = Date + String.Format("[{0}]\t", Importance) +"\t"+ string.Format(Format, pars);
                lock(this) {
                    StringQueue.Enqueue(Message);
                }
            }
        }
...
Рейтинг: 0 / 0
24.07.2013, 00:00
| Ответить | Цитировать | Написать  
9 сообщений из 34, страница 2 из 2
  2  все
Форумы / Программирование [игнор отключен] [закрыт для гостей] / вопрос по потокам
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=16&msg=38330583&tid=1341734]:
 0ms
get settings:
 7ms
get forum list:
 19ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 408ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 46ms
get tp. blocked users:
 1ms
others: 241ms
total:  744ms
созд. / загр.: 744ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]