Можно ли создать объект в фоновом потоке без ссылки на основной поток?

Question

Приложение для торговли акциями использует библиотеку классов для получения обратных вызовов при обновлении котировок акций, другую библиотеку классов для получения обратных вызовов при выполнении или отмене ордеров.В настоящее время я выполняю обратные вызовы в пуле потоков.Я запускаю один фоновый поток для каждого обратного вызова.Потоки очень недолговечны, и работа включает в себя получение данных и уведомление наблюдателей.Как только наблюдатели уведомлены, фоновая нить умирает.Когда у меня есть стратегии, подписывающиеся на более чем 1000 активно торгуемых символов, я получаю исключения OutOfMemory.

Как я могу улучшить этот дизайн?Я думал о запуске двух потоков в начале, одного для кавычек, другого для выполнения, и создания каждого объекта в соответствующих потоках.Тогда просто есть общий объект, который позволяет добавлять и удалять наблюдателей в потоках.Но 1) как бы вы поддерживали поток для получения обратных вызовов?2) Как вы можете иметь объект обратного вызова, который инициализируется в потоке без ссылки на основной поток?Это вообще возможно?

Буду признателен за любую помощь.

Answer 1

Используйте модель производитель / потребитель с простой очередью.Тогда у вас будет установлено заданное количество рабочих потоков, и у вас не возникнет этой проблемы.

Что касается как для вызова функции обратного вызова, вы можете использовать такую ​​структуру:

struct WorkerData
{
    Data data;
    Delegate someCallback;
}

когда работник заканчивает работу с данными, он может вызвать сам обратный вызов.

Answer 2

То, что вы описали, является общей картиной вашего приложения. Чтобы изменить дизайн вашего приложения, мы предъявляем конкретные требования и, по крайней мере, упрощенную модель взаимодействия участников друг с другом. Ваше неофициальное описание не является достаточно точным, чтобы предложить конкретную структуру данных и алгоритм, потому что, не зная всех достаточно подробностей, мы можем опустить что-то важное и не соответствовать вашим потребностям.

Вы говорите все правильные слова, и у вас есть конкретная проблема, нехватка памяти, и вам нужно что-то исправить. Вернитесь к прототипированию. Напишите очень маленькую, но жестоко тренированную программу, чтобы продемонстрировать, что вы хотите сделать. Затем масштабируйте его до своего приложения. Гораздо проще спроектировать размер прототипа.

Edit:

Поскольку у вас заканчивается память, наиболее вероятные причины: утечка памяти или просто система, работающая почти в реальном времени, с недостаточным объемом для обработки нагрузки, с которой вы столкнулись. Утечка может быть связана с обычными подозреваемыми, например, не отключать обработчики событий, которые вы можете диагностировать с помощью профилировщиков памяти, но пока мы это исключим.

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

Единственный способ решить эту проблему:

• бросить некоторые цитаты на пол
• получить лучшее оборудование
• обрабатывать котировки более эффективно

Я думаю, вы надеетесь, что есть четкая альтернатива более эффективной обработке кавычек с новой структурой данных или алгоритмом, который может иметь большое значение. Но даже если вы сделаете его более эффективным, проблема все равно может вернуться, и вам придется подумать о постепенном снижении производительности в условиях перегрузки, а не об отказе из-за недостатка памяти.

Но в общих чертах, для высокой производительности проще - лучше, и чем меньше потоков, тем лучше. Например, если работа, выполняемая в обновлении, невелика, синхронизация может быть большим выигрышем, даже если это кажется противоинтуитивным. Вы должны знать, что делает обработчик обновлений, и больше всего для системы, работающей почти в реальном времени, которую вы должны измерить, измерить, измерить, чтобы эмпирически узнать, какая из них самая быстрая.

Answer 3

Мне

В настоящее время я выполняю обратные вызовы в пуле потоков

и

Как только наблюдатели уведомлены, фоновый поток умирает

слегка противоречивы. Я подозреваю, что вы, возможно, намереваетесь использовать потоки из пула, но случайно используете новые «свободные» (не пулированные) потоки каждый раз.

Возможно, вы захотите взглянуть на документацию для Слабая ссылка .

Однако я предлагаю вам использовать профилировщик / perfmon, чтобы найти утечку ресурсов в первую очередь. Замена всего шебанга подходом к очередям звучит разумно, но это довольно близко к тому, что вы бы в любом случае имели с правильным пулом потоков.