invoke / delegate
а raise происходит из треда B, то handler запустится в треде A или в треде B?где raise произошел там и выполняется handler. Фактически raise события это — пробегаем по коллекции подписанных handler-ов и по очереди дергаем их.
что это за жепь? это атавизм или новшество?Это полезно. Только учитывай, что делегат в результате исполняется в _третьем_ треде (точнее, в тредпуле а не в том, в котором он создан.
Так что если ты хочешь исполнить именно в оригинальном, то, в случае винформ, юзай Control.Invoke (который запаковывает делегат в обычную виндовую мессагу и посылает контролу иначе изучай SynchronizationContext и дерайвнутые из него классы.
> (точнее, в тредпуле)
что за пул?
что за пул?
ThreadPool
Это такая хитрая штука, которая эмулирует много тредов одним. Типа, если у тебя много тредов, которые большую часть времени ждут чего-то, то маза их запускать в одном и тем же треде.
Это такая хитрая штука, которая эмулирует много тредов одним. Типа, если у тебя много тредов, которые большую часть времени ждут чего-то, то маза их запускать в одном и тем же треде.
Только учитывай, что делегат в результате исполняется в _третьем_ треде (точнее, в тредпуле а не в том, в котором он создан.почему в третьем(почему в threadpool-е)?
откуда его вызвали (из B) там и выполнится (в B). кто его в threadpool будет перебрасывать?
откуда его вызвали (из B) там и выполнится (в B). кто его в threadpool будет перебрасывать?Видимо, он перепутал непосредственно вызов делегата и вызов метода BeginInvoke.
Ой, действительно, извините.
Я как-то по дефолту думал, что он эквивалентен BeginInvoke без побочных эффектов от невызванного EndInvoke, а он нужен тупо для CLR-совместимости. То есть даже наоборот, на самом деле первичен Invoke, а шарп позволяет какбэ вызывать сам делегат.
Я как-то по дефолту думал, что он эквивалентен BeginInvoke без побочных эффектов от невызванного EndInvoke, а он нужен тупо для CLR-совместимости. То есть даже наоборот, на самом деле первичен Invoke, а шарп позволяет какбэ вызывать сам делегат.
эмулирует много тредов однимТолько почему-то при этом у каждого "эмулированного" треда id разный совсем.
Он просто помогает их организовать хорошо, а не эмулирует.
В ответ на:Оба утверждения неверны, или не совсем верны. Thread pool, как и любой pool, в первую очередь экономит на времени создания ресурсов.
эмулирует много тредов одним
Только почему-то при этом у каждого "эмулированного" треда id разный совсем.
Он просто помогает их организовать хорошо, а не эмулирует.
http://en.wikipedia.org/wiki/Thread_pool
Мы вообще-то обсуждаем вполне конкретную реализацию тред-пула.
Many applications create threads that spend a great deal of time in the sleeping state, waiting for an event to occur. Other threads might enter a sleeping state only to be awakened periodically to poll for a change or update status information. Thread pooling enables you to use threads more efficiently by providing your application with a pool of worker threads that are managed by the system. One thread monitors the status of several wait operations queued to the thread pool. When a wait operation completes, a worker thread from the thread pool executes the corresponding callback function.
...
When the thread pool reuses a thread, it does not clear the data in thread local storage or in fields that are marked with the ThreadStaticAttribute attribute. Therefore, data that is placed in thread local storage by one method can be exposed to any other method that is executed by the same thread pool thread. A method that accesses a field that is marked with the ThreadStaticAttribute attribute could encounter different data depending on which thread pool thread executes it.
...
When Not to Use Thread Pool Threads
...
* You need to have a stable identity associated with the thread
Many applications create threads that spend a great deal of time in the sleeping state, waiting for an event to occur. Other threads might enter a sleeping state only to be awakened periodically to poll for a change or update status information. Thread pooling enables you to use threads more efficiently by providing your application with a pool of worker threads that are managed by the system. One thread monitors the status of several wait operations queued to the thread pool. When a wait operation completes, a worker thread from the thread pool executes the corresponding callback function.
...
When the thread pool reuses a thread, it does not clear the data in thread local storage or in fields that are marked with the ThreadStaticAttribute attribute. Therefore, data that is placed in thread local storage by one method can be exposed to any other method that is executed by the same thread pool thread. A method that accesses a field that is marked with the ThreadStaticAttribute attribute could encounter different data depending on which thread pool thread executes it.
...
When Not to Use Thread Pool Threads
...
* You need to have a stable identity associated with the thread
Мы вообще-то обсуждаем вполне конкретную реализацию тред-пула.Вообще-то там нет ни слова про
хитрая штука, которая эмулирует много тредов одним
Ну не одним, много тредов меньшим количеством, так правильней? Хотя в некоторых задачах оно может и одним обойтись, наверное.
Нет, конечно оно не умеет выполнять несколько одновременно активных тредов в одном. Потому что это и есть треды, активные штуки в смысле. Но вот Выполнить десять последовательных задач в одном и том же треде оно умеет. Или повесить десять как бы тредов на какие-нибудь эвенты и выполнять их все в одном и том же треде, или в двух тредах, причём так, что конкретный эвент испольняется то в одном, то в другом, тоже умеет.
Единственное что — оно вроде таки не умеет перехватывать обычные вызовы блокирующихся примитивов. А было бы забавно.
Нет, конечно оно не умеет выполнять несколько одновременно активных тредов в одном. Потому что это и есть треды, активные штуки в смысле. Но вот Выполнить десять последовательных задач в одном и том же треде оно умеет. Или повесить десять как бы тредов на какие-нибудь эвенты и выполнять их все в одном и том же треде, или в двух тредах, причём так, что конкретный эвент испольняется то в одном, то в другом, тоже умеет.
Единственное что — оно вроде таки не умеет перехватывать обычные вызовы блокирующихся примитивов. А было бы забавно.
Оставить комментарий
state7401281
что это за жепь? это атавизм или новшество?и еще, если в многотредовом приложении event handler устанавливается в треде A, а raise происходит из треда B, то handler запустится в треде A или в треде B?