Потоки имеют отличную "кучу"?
Принимает подобную Unix систему на Python 2, который можно сделать:
import os
def tail(f, n, offset=0):
stdin,stdout = os.popen2("tail -n "+n+offset+" "+f)
stdin.close()
lines = stdout.readlines(); stdout.close()
return lines[:,-offset]
Для python 3 можно сделать:
import subprocess
def tail(f, n, offset=0):
proc = subprocess.Popen(['tail', '-n', n + offset, f], stdout=subprocess.PIPE)
lines = proc.stdout.readlines()
return lines[:, -offset]
6 ответов
Нет. Все потоки имеют общую кучу.
Каждый поток имеет частный стек , из которого он может быстро добавлять и удалять элементы. Это делает память на основе стека быстрой, но если вы используете слишком много памяти стека, как это происходит при бесконечной рекурсии, вы получите переполнение стека.
Поскольку все потоки используют одну и ту же кучу, доступ к распределителю / освободителю должен быть синхронизирован. Существуют различные методы и библиотеки, позволяющие избежать конфликта распределителей .
Некоторые языки позволяют создавать частные пулы памяти или отдельные кучи, которые можно назначать одному потоку.
По умолчанию C имеет только одну кучу.
Тем не менее, некоторые распределители, поддерживающие потоки, будут разбивать кучу так, чтобы каждый поток имел свою собственную область для выделения. Идея состоит в том, что это должно улучшить масштабирование кучи.
Одним из примеров такой кучи является Hoard .
Очевидно, что это не относится к вашей конкретной ситуации, но для всех, кто работает под Windows 7, хорошим вариантом является использование XP Mode . В образе XPM установлен IE6, и его срок действия не истечет, как у образов VPC, совместимых с приложениями Internet Explorer.
После установки режима XP создайте ярлык для IE в меню «Программы XP» (чтобы ярлык был опубликован в вашем Win 7 Пуск меню). Затем вы можете запустить IE6 одновременно с IE8 на рабочем столе Win 7.
это может быть немного сложнее. Возможно, вы ищете Локальное хранилище потока (TLS), но оно хранит только отдельные значения.Для Windows: TLS-пространство можно выделить с помощью TlsAlloc и освободить с помощью TlsFree (Обзор здесь ). Опять же, это не куча, а просто DWORD.
Как ни странно, Windows поддерживает несколько куч для каждого процесса. Дескриптор кучи можно сохранить в TLS. Тогда у вас будет что-то вроде «локальной кучи потока». Однако другим потокам неизвестен только дескриптор, они по-прежнему могут обращаться к его памяти с помощью указателей, поскольку это все то же адресное пространство.
РЕДАКТИРОВАТЬ : некоторые распределители памяти (в частности jemalloc на FreeBSD) используют TLS для назначения «арен» потокам. Это сделано для оптимизации распределения для нескольких ядер за счет уменьшения накладных расходов на синхронизацию.
Зависит от ОС. Стандартная среда выполнения c в Windows и Unices использует общую кучу между потоками. Это означает блокировку каждого malloc / free.
В Symbian, например, каждый поток имеет свою собственную кучу, хотя потоки могут совместно использовать указатели на данные, размещенные в любой куче. На мой взгляд, дизайн Symbian лучше, поскольку он не только устраняет необходимость блокировки во время выделения / освобождения, но также способствует четкой спецификации владения данными между потоками. Также в том случае, когда поток умирает, он принимает все объекты, которые он выделил вместе с ним, то есть он не может пропускать выделенные им объекты, что является важным свойством мобильных устройств с ограниченной памятью.
Erlang также следует за ним. аналогичная конструкция, в которой «процесс» действует как единица сборки мусора.
Каждый поток имеет свой собственный стек и стек вызовов.
Каждый поток использует одну и ту же кучу.
Обычно потоки совместно используют кучу и другие ресурсы, однако существуют конструкции, подобные потокам, которые этого не делают. Среди этих потоковоподобных конструкций - облегченные процессы Erlang и полнофункциональные процессы UNIX (созданные с помощью вызова fork () ). Вы также можете работать над параллелизмом между несколькими машинами, и в этом случае ваши возможности межпоточного взаимодействия значительно ограничены.