E.6 Различия между разными потоковыми пакетами

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

Существуют по меньшей мере три типа потоковых пакетов:

• Пользовательские потоки в одном процессе. Переключение потоков осуществляется сигналами (alarm) и библиотека потоков управляет всеми функциями, не поддерживающими потоки, с помощью блокировок. Операции чтения, записи и выборки обычно управляются программой выбора потоков, которая переключает их на другой поток, если текущий должен ожидать данные (речь идет о вызове select). Пакеты пользовательских потоков могут быть интегрированы в стандартные библиотеки (FreeBSD- и BSDI-потоки). Такие интегрированные пакеты требуют меньше затрат в сравнении с потоковыми пакетами, которые должны обрабатывать все ненадежные вызовы (MIT-pthreads, FSU Pthreads и потоки RTS). В некоторых средах (например SCO) все системные вызовы поддерживают потоки, так что обработка может быть выполнена очень просто (FSU Pthreads под SCO). Недостатки такого метода: поскольку все вызовы, для которых установлены соответствия, занимают мало времени, очень сложно контролировать обработку всех ситуаций. Обычно существуют также системные вызовы, не обрабатываемые потоковым пакетом (такие как MIT-pthreads и сокеты). Диспетчеризация потоков не всегда является оптимальной.
• Пользовательские потоки в раздельных процессах. Переключение потоков производится ядром и все данные используются совместно всеми потоками. Потоковый пакет управляет стандартными вызовами потоков, чтобы обеспечить совместное использование данных этими потоками. Такой метод используется в LinuxThreads. Недостатки этого метода: масса процессов; медленное создание потока. Если один поток умирает, то остальные обычно зависают и необходимо их уничтожать перед перезапуском. Переключение потоков отчасти затратно.
• Потоки ядра. Переключение потоков управляется потоковой библиотекой или ядром и происходит очень быстро. Все делается в одном процессе, но для некоторых систем ps может показывать разные потоки. Если один из потоков неожиданно умрет, то происходит аварийное прерывание всего процесса. Большинство системных вызовов поддерживают потоки и должны требовать очень небольших затрат. С потоками ядра работают Solaris, HP-UX, AIX и OSF/1.

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

User Comments

something that they never get into in this
documentation is how to effectively use it
(period) in a SQL query with, oh, tables, and
columns. :)

select users from table where first_name REGEXP
\"^[RBrb]ob\";

will select all users that have names that start
with rob/bob (first character case insensitive)

Those of us who use DBI + Perl or php can
certainly make effective use of this.

erik, this is described here:
http://www.mysql.com/doc/en/Pattern_matching.html

If you are searching for literal
parentheses, you
have to enclose each parenthesis in brackets;
otherwise, mySQL thinks they're part of the
regular expression syntax. For instance:

WHERE phone REGEXP '(435)';

would return any phone numbers that have the
sequence 435 in any part of the string, such as
"1(801)555-4351". However:

WHERE phone REGEXP '[(]435[)]';

would return only phone numbers with (435), such
as "1(435)555-5555".

I've a question concerning negations of regular
expressions - e.g. I want the sentence "this is
nice" to match, while the sentence "this is not
nice" should not match. I only found possibilities
for the negation of single characters in this
tutorial, but what about whole words?!

Thanks for the reference to http://www.mysql.com/doc/en/Pattern_matching.html, fragking (there
really should be a "see also" link to it
somewhere on this doc page.) I couldn't get
REGEXP to work right for me till I found a VERY
IMPORTANT note on the Pattern Matching page
regarding case-sensitivity:

"Prior to MySQL Version 3.23.4, REGEXP is case
sensitive.... From MySQL 3.23.4 on, to force a
REGEXP comparison to be case sensitive, use the
BINARY keyword to make one of the strings a
binary string."

So I finally got my REGEXP (which searches for
any uppercase letters in a user id) to work
correctly:

mysql> SELECT * FROM tblTimePunch WHERE eid
REGEXP BINARY "[A-Z]";

Putting the column last is handy too:
select * from table where "Joe Bob Jim" regexp
name

Add your own comment.