|
Lock
|
|||
---|---|---|---|
#18+
В каноничных примерах ( тут или тут ) для блокировки числового поля используется дополнительный объект, а если поле объектное, то можно ли его самого в Lock воткнуть? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2018, 11:41 |
|
Lock
|
|||
---|---|---|---|
#18+
Antonariy, Блокируется кусок кода между скобками. Другой поток встанет на скобке и будет ждать. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2018, 11:49 |
|
Lock
|
|||
---|---|---|---|
#18+
Antonariy, можно, но не нужно, пару байт жалко? лучше сделать поле с объектом синхронизации\блокировки private readonly, как мне кажется, в большинстве случаев ... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2018, 11:58 |
|
Lock
|
|||
---|---|---|---|
#18+
Roman MejtesAntonariy, можно, но не нужно, пару байт жалко?не мне. я сейчас работаю в таком месте, где докапываются даже до кошерного переноса => то есть void xxx() => yyy(); не правильно, а void xxx() => yyy(); правильно. вот и насчет блокировки примерно такая же ерунда. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2018, 12:33 |
|
Lock
|
|||
---|---|---|---|
#18+
Roman MejtesAntonariy, можно, но не нужно, пару байт жалко? лучше сделать поле с объектом синхронизации\блокировки private readonly, как мне кажется, в большинстве случаев Это не пара байт, а прикручивание к каждому блокируемому объекту прилипалы ... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2018, 14:09 |
|
Lock
|
|||
---|---|---|---|
#18+
ViPRosRoman MejtesAntonariy, можно, но не нужно, пару байт жалко? лучше сделать поле с объектом синхронизации\блокировки private readonly, как мне кажется, в большинстве случаев Это не пара байт, а прикручивание к каждому блокируемому объекту прилипалы в процессе выполнения указатель может поменяться, а у private readonly object'а поля он гарантированно постоянный ... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2018, 14:29 |
|
Lock
|
|||
---|---|---|---|
#18+
AntonariyВ каноничных примерах ( тут или тут ) для блокировки числового поля используется дополнительный объект, а если поле объектное, то можно ли его самого в Lock воткнуть? Все зависит от конкретной ситуации. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2018, 15:02 |
|
Lock
|
|||
---|---|---|---|
#18+
Roman Mejtesв процессе выполнения указатель может поменяться, а у private readonly object'а поля он гарантированно постоянный Неужто прямо у объекта под Lock поменяют указатель и при том не поменяют в таблице локов? Дебилы что ли? Где это написано? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2018, 15:34 |
|
Lock
|
|||
---|---|---|---|
#18+
Antonariy для блокировки числового поля используется дополнительный объект, а если поле объектное, то можно ли его самого в Lock воткнуть? использовать не блокирующую синхронизацию, локами из пушки по воробьям ... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2018, 18:59 |
|
Lock
|
|||
---|---|---|---|
#18+
Где-то в степи, Интересный момент стоимость локов. Если за ресурс нет конкуренции то лок в два раза медленней чем interlocked Exchange. Если изменения затрагивают только одно машинное слово - то интрлок быстрее. Но обычно всё же необходимы измененя в нескольких словах, и вот тут уже ситуация меняется: уже два интерлока медленнее (не быстрее) чем один лок потому что сбрасывают две линии прцессорного кэша. Выбор оптимальной парадигмы для синхронизации очень не прост, но обобщённо утверждать локи - пушка я бы не стал. С учётом теннденций в ИТ к дешевизне с приемлемыми потерями в качестве - локи лучше. Лучше медленно но верно чем быстро но иногда. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2018, 20:40 |
|
Lock
|
|||
---|---|---|---|
#18+
mikron, согласен, сам грешу шлепнешь бывало synchronized и попер дальше, но залочить доступ к числовому полю, как то рука не поднимется даже всуе... ... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2018, 20:50 |
|
Lock
|
|||
---|---|---|---|
#18+
AntonariyВ каноничных примерах ( тут или тут ) для блокировки числового поля используется дополнительный объект, а если поле объектное, то можно ли его самого в Lock воткнуть? Для таких типов, как в примере по первой ссылке (class Account), и, соответственно в таких методах (Debit/Credit), не заморачиваясь лочу сам объект (lock (this)), в более сложных типах иногда приходится использовать несколько мютексов (тогда, в соотв.методах lock (mutex1)/lock (mutex2)/lock (mutexN)). Для коллекций использую то что Сон Веры Павловны прописал - ICollection.SyncRoot (стоит лишь одного using-a System.Collections) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2018, 01:21 |
|
Lock
|
|||
---|---|---|---|
#18+
Где-то в степино залочить доступ к числовому полю, как то рука не поднимется даже всуе... а к локальной переменной в методе (как к самой потоконезащищенной сущности)? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2018, 01:52 |
|
Lock
|
|||
---|---|---|---|
#18+
LRГде-то в степино залочить доступ к числовому полю, как то рука не поднимется даже всуе... а к локальной переменной в методе (как к самой потоконезащищенной сущности)? У каждого потока (Thread) свой стэк выполнения, и соотв локальная переменная метода для каждого потока своя. Во-вторых, компилятор может соптимизировать так, что локальной переменной не будет вовсе как объекта в памяти, к чему тогда лочить доступ? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2018, 04:55 |
|
Lock
|
|||
---|---|---|---|
#18+
LRГде-то в степино залочить доступ к числовому полю, как то рука не поднимется даже всуе... а к локальной переменной в методе (как к самой потоконезащищенной сущности)? все наоборот :) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2018, 10:41 |
|
Lock
|
|||
---|---|---|---|
#18+
PallarisLRпропущено... а к локальной переменной в методе (как к самой потоконезащищенной сущности)? У каждого потока (Thread) свой стэк выполнения, и соотв локальная переменная метода для каждого потока своя. Во-вторых, компилятор может соптимизировать так, что локальной переменной не будет вовсе как объекта в памяти, к чему тогда лочить доступ? Да, действительно, что-то не то ляпнул, виноват)) Но "залочить доступ к числовому полю" (type member) все же нужно, рука должна подниматься)) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2018, 11:04 |
|
Lock
|
|||
---|---|---|---|
#18+
LRНо "залочить доступ к числовому полю" (type member) все же нужно, рука должна подниматься))если оно одинокое) то зачем? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2018, 11:12 |
|
Lock
|
|||
---|---|---|---|
#18+
Petro123LRНо "залочить доступ к числовому полю" (type member) все же нужно, рука должна подниматься))если оно одинокое) то зачем? теперь расшифруй поток ботосознания ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2018, 11:23 |
|
Lock
|
|||
---|---|---|---|
#18+
ViPRosPetro123пропущено... если оно одинокое) то зачем? теперь расшифруй поток ботосознанияэллочке-людоедке зачем расшифровывать. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2018, 12:33 |
|
Lock
|
|||
---|---|---|---|
#18+
AntonariyВ каноничных примерах ( тут или тут ) для блокировки числового поля используется дополнительный объект, а если поле объектное, то можно ли его самого в Lock воткнуть? Можно-то можно. Но не нужно :) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.11.2018, 13:08 |
|
Lock
|
|||
---|---|---|---|
#18+
Распараллеливаю код, который разными функциями наполняет разные поля у записей в одной коллекции. Коллекция не меняется, потоки гарантированно не будут менять одни и те же поля, и даже тут пишут, что все ок: https://stackoverflow.com/questions/28641283/multiple-threads-accessing-a-single-object-but-without-data-contention-in-c-shar Однако второй камент какой-то противоречивый. В первой части говорит, что хреновая идея тут потокобезопасность наворачивать, а во второй, что таки давайте. А что МСДН по этому поводу говорит? Я не нашел ничего подходящего по смыслу. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2018, 17:42 |
|
Lock
|
|||
---|---|---|---|
#18+
Antonariy, Да при чем тут МСДН? Если ты уверен, что нет конкуренции, то и не о чем думать. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2018, 17:49 |
|
|
start [/forum/topic.php?fid=20&msg=39729969&tid=1399167]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
60ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
others: | 19ms |
total: | 168ms |
0 / 0 |