Что-то мне подсказывает, что оксидную пленку срывает (сцарапывает) контактная пластина и прижимная пружина, а паста не позволяет ей образоваться опять.
В методе TIOCPSocketProto.Read:
при формировании исключения sErrorRead_WSARecv сбрасывается блокировка, а при исключении sErrorRead_GetMem — остается в заблокированном состоянии.
Если используется ThreadPool то для чего были созданы целых три отдельных нитки для обработки событий?
Насколько я понимаю, события можно обрабатывать при помощи RegisterWaitForSingleObject.
neptunspb.ru/products/components/sensor/
Так как на выходе практически всех датчиков для систем защиты от протечек стоит транзистор с открытым коллектором, то незначительно доработать контроллер для поддержки любого количества сенсоров не составляет никаких проблем…
В свое время при решении аналогичной проблемы воспользовался Interlocked SList которые реализует односвязанный список.
Добавление данных при помощи метода InterlockedPushEntrySList.
Выборка данных путем очистки выборки и одновременной очистки всего стека и последующего его переворота.
Ниже приведен кусок часть delphi кода по реализации добавления и выборки данных.
function T_InterlockedQueue.PopAll: I_IntrefaceEnumerator;
var
head: PInterlockedQueueItem;
begin
head := RevertSList(PInterlockedQueueItem(InterlockedFlushSList(FHeader)));
Result := T_InterfaceEnumerator.Create(head);
end;
procedure T_InterlockedQueue.Push(const AItem: IInterface);
var
listItem: PInterlockedQueueItem;
begin
listItem := GetMemory(sizeof(T_InterlockedQueueItem));
ZeroMemory(listItem, sizeof(T_InterlockedQueueItem));
listItem.Data := AItem;
InterlockedPushEntrySList(FHeader, PSLIST_ENTRY(listItem));
end;
CREATE INDEX I_Deal1 ON Deal (CustomerID, DealDate)
CREATE INDEX I_Deal2 ON Deal (CustomerID, DealDate desc)
CREATE INDEX I_Deal3 ON Deal (DealDate desc, CustomerID)
CREATE INDEX I_Deal3 ON Deal (DealDate, CustomerID)
Разницы никакой не обнаружил.
По результатам изучения Execution Plan для скриптов, которые приложены к примеру, в любом случае при использовании ROW_NUMBER сначала производится расставление номеров для всех строк, т.е. до фильтра «t.rn <= 10» доходит больше миллиона строк, а уже только после фильтрации получается 30 строк.
При этом никаких площадок не требуется.
при формировании исключения sErrorRead_WSARecv сбрасывается блокировка, а при исключении sErrorRead_GetMem — остается в заблокированном состоянии.
2. Под пулом я имел в виду в том числе WinApi функцию a href=«msdn.microsoft.com/en-us/library/windows/desktop/aa363484(v=vs.85).aspx»>BindIoCompletionCallback
Насколько я понимаю, события можно обрабатывать при помощи RegisterWaitForSingleObject.
Так как на выходе практически всех датчиков для систем защиты от протечек стоит транзистор с открытым коллектором, то незначительно доработать контроллер для поддержки любого количества сенсоров не составляет никаких проблем…
Выборка данных путем полной выборки и одновременной очистки всего стека и последующего переворота выбранных данных.
Добавление данных при помощи метода InterlockedPushEntrySList.
Выборка данных путем очистки выборки и одновременной очистки всего стека и последующего его переворота.
Ниже приведен кусок часть delphi кода по реализации добавления и выборки данных.
Разницы никакой не обнаружил.
По результатам изучения Execution Plan для скриптов, которые приложены к примеру, в любом случае при использовании ROW_NUMBER сначала производится расставление номеров для всех строк, т.е. до фильтра «t.rn <= 10» доходит больше миллиона строк, а уже только после фильтрации получается 30 строк.
В таблице customer 5000 записей, в таблице Deal около 10 миллионов.
Используя OUTER APPLY:
Время исполнения: 1 сек
Estimated subtree cost: 0,17.
Profiler — CPU: 765
Profiler — Reads: 34973
Profiler — Duration: 783
Используя ROW_NUMBER estimated subtree cost 450.00.
Время исполнения: 48 сек
Estimated subtree cost: 450,00.
Profiler — CPU: 125979
Profiler — Reads: 41707
Profiler — Duration: 47346