WaitHandle AsyncWaitHandle

голоса
1

Я реализую службу WCF , которая в конечном итоге работает несколько хранимых процедур в базе данных она называет BeginExecuteReaderи BeginExecuteScalar. Я не могу решить , что AsyncWaitHandleреализация мне нужно. Я думал о 2 варианта:

  1. Прост:

    public System.Threading.WaitHandle AsyncWaitHandle
    {
        get
        {
            return m_manualResentEvent;
        }
    }
    
  2. Который использует блокировку для защиты m_ManualResentEvent

    public WaitHandle AsyncWaitHandle
    {
        get
        {
            if (m_manualResentEvent!= null)
            {
                return m_manualResetEvent;
            }
            lock (ThisLock)
            {
                if (m_manualResetEvent == null)
                {
                    m_manualResetEvent = new ManualResetEvent(isCompleted);
                }
            }
            return m_manualResetEvent;
        }
    }
    
Задан 19/01/2014 в 09:48
источник пользователем
На других языках...                            


2 ответов

голоса
1

WCF не будет использовать событие в любом случае , потому что уничтожит любые повышения эффективности. Если вы делаете асинхр для повышения эффективности и / или масштабируемости, никогда не используйте ожидания ручки. Бросок NotImplementedException.

Ответил 19/01/2014 в 13:15
источник пользователем

голоса
1

Обновить

Как упоминалось в комментариях, вы реализуете IAsyncResult. Я могу найти два образца от Microsoft здесь и здесь . В обоих случаях, они пошли за второй вариант. Я могу только думать , что это было сделано именно так , потому что ManualResetEvent не всегда используется, так что это экономит ресурсы , чтобы создавать только в случае необходимости.

оригинал

Первый, кажется, имеют меньше возможностей для резьбонарезания раздора (ждет блокировки), не теряя ничего, насколько я могу видеть. Я предполагаю, что в первой опции ManualResetEvent является членом экземпляра, который инициализируется в конструкторе. Если да, то я пошел бы с первым.

Насколько вероятно, использовать это событие? Если это не так, вероятно, вообще, то вы можете рассмотреть вопрос о второй, так как это избавит вас от потребления ресурса и нить утверждение вряд ли.

Ответил 19/01/2014 в 09:55
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more