Теория коммуникации потока
если столбец электронной почты содержит ноль,
Это должно сработать.
SELECT COUNT(!ISNULL(email)) FROM company
5 ответов
Действительно, это все равно как любая проблема параллелизма: у Вас есть несколько потоков управления, и это неопределенно, какие операторы, на которых потоки выполняются когда. Это означает, что существует большое количество ПОТЕНЦИАЛЬНЫХ путей выполнения через программу, и Ваша программа должна быть корректной под всеми ними.
В целом место, где проблема может произойти, - когда состояние является общим для потоки (иначе "легкие процессы" в былые времена.), Который происходит, когда существуют области общей памяти,
Гарантировать правильность, что необходимо сделать, гарантируют, что эти области данных обновляются способом, который не может вызвать ошибки. Чтобы сделать это, необходимо определить "критические разделы" программы, где последовательная операция должна быть гарантирована. Это может быть так же мало как единственная инструкция или строка кода; если язык и архитектура гарантируют, что они являются атомарными, то есть, не может быть прерван, то Вы являетесь золотыми.
Иначе, Вы idnetify, которые разделяют и помещают некоторую защиту на него. Классический путь состоит в том, чтобы использовать семафор, который является атомарным оператором, который только позволяет один поток управления мимо за один раз. Они были изобретены Edsgar Dijkstra, и тем самым имейте имена, которые прибывают из голландцев, P и V. Когда Вы приезжаете в P, только один поток может продолжиться; все другие потоки ставятся в очередь и ожидающий, пока выполняющийся поток не прибывает в связанное V операций.
Поскольку эти примитивы являются небольшим примитивом, и потому что голландские имена не очень интуитивны, были некоторые там разработанные подходы более широкого масштаба.
На Brinch-Hansen изобрел монитор, который является в основном просто структурой данных, которая начинает операции, которые гарантируются атомарные; они могут быть реализованы с семафорами. Мониторы в значительной степени что Java synchronized операторы на основе; они заставляют объектный или блок кода иметь тот конкретный behavir - то есть, только один поток может быть "в" них за один раз - с более простым синтаксисом.
Существуют другие modeals возможные. Haskell и Erlang решают проблему, будучи функциональными языками, которые никогда не позволяют переменной быть измененной, после того как она создается; это означает, что они естественно не должны волноваться о синхронизации. Некоторые новые языки, как Clojure, вместо этого имеют структуру, названную "транзакционная память", которая в основном означает, что, когда существует присвоение, Вам гарантируют, присвоение является атомарным и обратимым.
Так вот именно вкратце. Действительно узнать об этом, лучшие места для рассмотрения текстов Операционных систем, как, например, текста Andy Tannenbaum.
Два наиболее распространенных механизма для коммуникации потока являются общим состоянием и передачей сообщений.
Если Вы действительно интересуетесь теорией связи потока, можно хотеть изучить формализм как Исчисление пи.
Наиболее распространенный способ к потокам для передачи через некоторую структуру совместно используемых данных, обычно очередь. Некоторые потоки помещают информацию в очередь, в то время как другие вынимают ее. Очередь должна быть защищена средствами операционной системы, такими как взаимные исключения и семафоры. Прерывания не имеют никакого отношения к нему.
Для передачи между потоками необходимо будет использовать любой механизм, предоставляется операционной системой и/или временем выполнения. Прерывания были бы необычно низким уровнем, хотя они могли бы использоваться неявно, если Ваши потоки передают сокеты использования или именованные каналы.
Общий шаблон должен был бы реализовать общее состояние с помощью блока общей памяти, полагаясь на предоставленную OS синхронизацию, примитивную, такую как взаимное исключение для экономии Вас от активного ожидания когда Ваше чтение от блока. Помните, что, если у Вас есть потоки вообще, затем у Вас уже должен быть некоторый планировщик (является ли это собственным от ОС или эмулированное в Вашем времени выполнения языка). Таким образом, этот планировщик может обеспечить объекты синхронизации и функцию "сна", обязательно не имея необходимость полагаться на поддержку оборудования.
Сокеты, каналы и общая память работают между процессами также. Иногда время выполнения будет давать Вам более легкий вес способ сделать синхронизацию для потоков в рамках того же процесса. Общая память является более дешевой в рамках единственного процесса. И иногда Ваше время выполнения будет также давать Вам атомарный механизм передачи сообщений.