|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
Где-то в степиbazile, причем тут lock и синхронизация потоков? куча такой же разделяемый ресурс между потоками, как и то о чем вы думаете. только синхронизация доступом к куче управляется ядром системы, если один поток создает в куче что то new а другой пытается создать то же что то или изменить размер уже созданного что то, то система ставит эти потоки в очередь для обращения ( один изменяет, другой ждет) И эти люди запрещают мне ковыряться в носу) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2014, 22:30 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
Где-то в степи, одновременное выделение памяти разными потоками в куче разумеется невозможно. Эти действия должны выполняться по очереди. Но доступ к уже выделенной памяти из разных потоков никакой очередности не предполагает. И поэтому для синхронизации одновременного доступа и нужен lock. Согласен? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 01:35 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
bazile, доступ это же абстрактность, на чтение какие могут быть ограничения? там принцип - кто первый тот и папа, а в лучшем случае данные берутся из кеша данных ядра ( ну куда не лазя), вопрос стоит - если поток написан без духовных скреп в различными излишествами расползающимися в куче, бездумными боксингами, без алокации на стеке, то как результат он будет постоянно сидеть на блокировке к обращению к куче. Говоря по русский - с дуру можно сломать x, или поговорка об опрятии религиозного культа индивидуума, который только только приобщился к оному... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 09:39 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
Где-то в степиbazile, доступ это же абстрактность, на чтение какие могут быть ограничения? там принцип - кто первый тот и папа, а в лучшем случае данные берутся из кеша данных ядра ( ну куда не лазя), вопрос стоит - если поток написан без духовных скреп в различными излишествами расползающимися в куче, бездумными боксингами, без алокации на стеке, то как результат он будет постоянно сидеть на блокировке к обращению к куче. Говоря по русский - с дуру можно сломать x, или поговорка об опрятии религиозного культа индивидуума, который только только приобщился к оному... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 09:47 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
bazileГде-то в степи, одновременное выделение памяти разными потоками в куче разумеется невозможно. Эти действия должны выполняться по очереди. Выделение памяти в куче в .NET почти атомарная операция. 1. Возвращаем указатель на вершину кучи. 2. Увеличиваем размер указателя на величину выделенной памяти. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 10:26 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
Где-то в степи, ты настолько абстрактно рассуждаешь, что понять о каких блокировках идет речь понять решительно невозможно. Перейдем к конкретике. Есть простой класс: Код: c# 1. 2. 3. 4.
Пример №1. Два потока читающие данные из разных переменных в куче. Есть ли здесь блокировки при обращении к куче? Если да, то в какие моменты и кто эти блокировки ставит. Код: c# 1. 2. 3. 4. 5.
Пример №2. Два потока записывающие данные в разные переменные в куче. Те же вопросы что для №1. Код: c# 1. 2. 3. 4. 5.
Пример №3. Два потока записывающие данные в общую переменную в куче. Те же вопросы что для №1. Код: c# 1. 2. 3. 4. 5. 6.
Пример №4. Запись в общую переменнную + lock. Те же вопросы что для №1. Код: c# 1. 2. 3. 4. 5. 6.
Хочется понять на этих примерах о каких блокировках сто стороны .NET/CLR идет речь. Опустим уровни ниже - Windows и процессор. Речь только о блокировках для .NET кучи. Приветствуются собственные примеры :) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 20:38 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
ЕвгенийВВыделение памяти в куче в .NET почти атомарная операция. 1. Возвращаем указатель на вершину кучи. 2. Увеличиваем размер указателя на величину выделенной памяти. "Почти атомарная" это интересный термин :) Я в курсе что выделение памяти в .NET так устроено. Можно предположить что изменение указателя кучи делается через Interlocked.Add() или его аналог. Здесь и будет получаться "очередь" о которой я говорил. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 20:41 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
вы все упороты ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 21:23 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
bazile, а может рихтера почитать windows для профессионалов, как работают потоки с кучей или с кучами ( впрочем их может быть несколько) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 23:13 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
bazile, во всех ваших примерах происходит упаковка значения и присвоение ссылки переменной. то есть происходит запрос на выделение памяти из кучи нeapаlloc с попутным заполнением оной и возвращается ссылка на на объект в этой памяти . так как указатель на динамическую кучу один для всех потоков и если два потока обратились одновременно к куче на создание, ядро ( сервер приложения api) ставит эти потоки в очередь на обращение, потому что так (( в результате выделения и записи может произойти казус, почти не атомарный, кучи может не хватить, тогда возникнет исключение в ядре, это исключение отловит менеджер кучи и добавит памяти для кучи из ситстемы, но добавит в займы, при уборке если выяснятся излишки менеджер отдаст ее обратно.. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 23:38 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
Где-то в степи, Постесняюсь спросить, а где хранятся value типы? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2014, 00:36 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
ЕвгенийВа где хранятся value типы? везде- в куче, стеке, регистрах ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2014, 00:44 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
ИзопропилЕвгенийВа где хранятся value типы? везде- в куче, стеке, регистрах А какой командой в C# запихнуть что нибудь в регистр? Просвятите магистр?:) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2014, 00:50 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
ЕвгенийВ, ставьте первым или вторым параметром, очень большая вероятность что окажется в регистре ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2014, 01:00 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
ЕвгенийВкакой командой в C# запихнуть что нибудь в регистр? Просвятите магистр?:) в c# нет команд если что. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2014, 01:01 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
bazile, автор что понять о каких блокировках идет речь понять решительно невозможно уточню, о блокировке к доступу к куче, то что вы приводите: мониторы аки критические секции, это вообще к обращению к куче не относится - это межпотоковое взаимодействие, хотя и базируется на реальных айпи.. а абстрактность о которой я говорю - данные можно получить из кучи сделав физический запрос , а можно из кеша данных процессора за пару тактов, говорят что попадание очень высокое ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2014, 01:38 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
Где-то в степито есть происходит запрос на выделение памяти из кучи нeapаlloc с попутным заполнением оной и возвращается ссылка на на объект в этой памяти . Ты путаешь кучу Windows c управляемой кучей. Вызов HeapAlloc будет происходить для выделеления памяти под управляемую кучу. После этого при вызове new выделение памяти сводится к перемещению указателя. Управляемой кучи конечно тоже может не хватить и тогда понадобится новый участок памяти и новый вызов HeapAlloc. Однако данный сценарий является частным случаем и срабатывает далеко не всегда т.к. место в управляемой куче выделяется с запасом как раз с целью избежать обращений к WinAPI. В итоге твоя фраза "ибо есть такое ограничение (из рихтера) из потоков обращение к куче может делать только один поток, остальные ждут, пока куча освободится" сводится к редкому сценарию выделения нового участка для управляемой кучи. Так что Алексей К был прав. Это в самом деле "Экономия на спичках." в контексте задачи работы с БД. Где-то в степиво всех ваших примерах происходит упаковка значения и присвоение ссылки переменной. Я вижу упаковку (boxing) только в примере №1 в вызове Console.WriteLine(). Где иы увидел упаковку в остальных примерах для меня загадка. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2014, 12:10 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
bazileЯ вижу упаковку (boxing) только в примере №1 в вызове Console.WriteLine(). Где иы увидел упаковку в остальных примерах для меня загадка. Господь с Вами батенька! Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9.
Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31.
... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2014, 14:49 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
ЕвгенийВ, упаковка происходит не в момент вызова, а ниже по следующей цепочке: Console.WriteLine(int) -> Console.Out.WriteLine(int) -> this.Write(int) -> this.Write(value.ToString(this.FormatProvider)); ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2014, 15:01 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
bazileЕвгенийВ, упаковка происходит не в момент вызова, а ниже по следующей цепочке: Console.WriteLine(int) -> Console.Out.WriteLine(int) -> this.Write(int) -> this.Write(value.ToString(this.FormatProvider)); Стек вызовов. Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2014, 15:36 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
При вызове методов структур упаковки-распоковки не происходит! Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Код: msil 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.
... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2014, 15:42 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
ЕвгенийВ, ты прав. Упаковки нет. Я перепутал это с ситуацией когда мы явно приводим значение value типа к интерфейсу и обращаемся к его членам. Тогда упаковка выполняется. P.S. Надо бы перечитать четвертое издание CLR via C# :) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2014, 16:12 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
bazile,авторТы путаешь кучу Windows c управляемой кучей Я вас не понял, я всегда считал что управляемая куча, это обыкновенная куча "Windows " над которой наблюдает мусорщик. ну а стратегия выделения памяти, это просто стратегия выделения свободного места , любая куча может быть динамической и нет, может освобождать блоки, может делать дефрагментацию, может иметь синхронный доступ для потоков, но по умолчанию он отключен, и рекомендуют его включать только при одно поточном режиме или доступ потоков к куче синхронизируется программно из вне. Выходит есть какие то особые кучи и с которыми ядро работает по своим правилам? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2014, 21:51 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
Где-то в степиЯ вас не понял Предлагаю на ты. Где-то в степия всегда считал что управляемая куча, это обыкновенная куча "Windows " над которой наблюдает мусорщик. Технически куча .NET является частью кучи Windows. .NET запрашивает память у Windows блоками и "выделяет" память внутри этого блока. Эти блоки и есть управляемая куча. Запрос к WinAPI делается только за новым большим блоком. Такой подход избавляет от необходимости обращаться при каждом new T() к Windows, ускоряя выделение памяти в управляемой куче. Где-то в степиВыходит есть какие то особые кучи и с которыми ядро работает по своим правилам? Ты пытаешься на слишком низком уровне это анализировать. Это нужно и полезно, но в данном случае ведет к неточным выводам. .NET запросила память в куче потока и делает с этой памятью все что ей нужно - выделяет память при new(), организует сборку мусора, дефрагментирует и т.д. Ядро к участку памяти занятой кучой .NET никаких особых правил не применяет. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2014, 01:22 |
|
Нужен совет по реализации многопоточного приложения
|
|||
---|---|---|---|
#18+
Вообще куча, некая абстракция, которая подразумевает алгоритм выделения-высвобождения памяти. При желании и наличии мозгов, можно реализовать самому. В стандартной, по умолчанию тупо храниться список свободных-занятых участков. И выделение памяти подразумевает поиск по списку участка подходящего размера. Не самые глупые люди постарались и сделали свою реализацию, которая избавляет программистов от многих проблем. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2014, 08:18 |
|
|
start [/forum/topic.php?fid=20&msg=38643630&tid=1402922]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
950ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 1064ms |
0 / 0 |