Добычу попкорна национализируют
Публикация в новостях - "Adobe подала регуляторам официальную жалобу на Apple".
Цитата:
"Министерство юстиции США и Комиссия по международной торговле заинтересовались политикой Apple в отношении технологии Flash. По информации BusinessWeek, их внимание к проблеме было привлечено жалобой, которую подал разработчик этой технологии компания Adobe.
Антимонопольщики собираются проверить Apple на предмет законности требований компании использовать только ее собственные инструменты для разработки приложений для смартфонов iPhone, планшетов iPad и плееров iPod touch. Как пишет The New York Post со ссылкой на анонимный источник, два ведомства в настоящий момент определяют, кто именно будет рассматривать это дело. ..."
UPD 1. Публикация в новостях - "Apple заинтересовались регуляторы".
Цитата:
"Министерство юстиции США и Комиссия по международной торговле заинтересовались политикой Apple в отношении технологии Flash. По информации BusinessWeek, их внимание к проблеме было привлечено жалобой, которую подал разработчик этой технологии компания Adobe.
Антимонопольщики собираются проверить Apple на предмет законности требований компании использовать только ее собственные инструменты для разработки приложений для смартфонов iPhone, планшетов iPad и плееров iPod touch. Как пишет The New York Post со ссылкой на анонимный источник, два ведомства в настоящий момент определяют, кто именно будет рассматривать это дело. ..."
UPD 1. Публикация в новостях - "Apple заинтересовались регуляторы".
Транзакционная память
В процессе подготовки материала к продолжению "Разбираемся с JBoss Transactions. Часть 1", пришлось как раз изучить, что такое эта транзакционная память - "Software transactional memory (Википедия, English)".
Достаточно сказать, что она вошла в состав новейшего .NET 4, вполне достаточно, чтобы попробовать изучить.
Как явствует из Википедии (ссылка выше) - это модель работы с многопоточностью, применяемая часто в СУБД, которая коренным образом отличается от lock-модели.
Плюсы достаточно интересны - во-первых она более проста для понимания и использования, чем lock-модель. Во-вторых она может быть и более быстрой (не всегда, но при каких-то условиях и сильно еще зависит от конкретной реализации). В-третьих, по уверению авторов, она менее подвержена такому КРАЙНЕ нехорошему моменту в многопоточности, как инверсия приоритетов. О последнем могут не беспокоиться пользователи операционной системы реального времени QNX, а вот пользователи Windows большинства версий, Linux, FreeBSD - мягко говоря - "сосут лапу", их ОС не защищены от инверсии приоритетов в многопоточности. При определенных обстоятельствах поток с небольшим приоритетом может не получать возможность работы относительно долго, вполне достаточно для непредотвращения взрыва ядерного реактора ответственным за глушение его потоком выполнения.
Итак, чем же характеризуется модель многопоточного программирования "Транзакционная память". Модель очень проста:
1) Есть какое-то место в программе, разделяемое между несколькими потоками, какие-то данные, для краткости назовем их переменными "a" и "b".
2) Нужно обеспечить атомарность изменения переменных "a" и "b" разными потоками. Например поток 1-ый делает инкремент обеим переменным, 2-ой - декремент обеим этим переменным, при этом нужно чтобы потоки делали этим изменения последовательно, сначала один из них начал работу, закончил, только тогда второй поток может тоже начать изменять их.
3) Lock-модель делает блокировку этого места в коде. При этом только один поток работает с залоченными местом в коде, остальные потоки ждут, когда и им дадут возможность поработать с этим местом кода тоже. Транзакционная память делает иначе - она позволяет ВСЕМ получать доступ к этому месту кода. Фишка тут в следующем, - ПЕРЕД тем как начать изменять (или просто считывать) переменные "a" и "b" - выполняющийся поток увеличивает значение или изменяет флаг какой-то особой переменной, выделенной для этой цели - назовем эту переменную как "z". Смотрите - поток изменяет флаг в "z", после этого работает с участком кода, где переменные "a" и "b". ПОСЛЕ этого, как данный поток внес изменения в "a" и "b" - он проверяет значение флага в переменной "z". Если значение флага в "z" не изменилось, значит никто не "покусился" за это время на переменные "a" и "b". Если изменилось, значит транзакция нарушена и, что нужно сделать в таком случае? - правильно, откат транзакции! Поток еще раз пробует поставить значение флага "z" и внести изменения в переменные "a" и "b". Все очень зависит от процессора и подсистем памяти - вполне возможно, что многие потоки получат достаточно времени, что гарантированно внести изменения в это место - и успеть поставить флаг и поменять обе переменные, пока данный поток не будет вытеснен другим потоком.
И дело вот еще в чем, про это не знает абсолютное большинство Java-программистов - вы можете затипизировать переменные "a" и "b" особыми атомарными типами, которые есть в Java. Да вот в чем незадача - атомарность эта достигается за счет полного блокирования системной шины. Ваша система может таким "колом" встать от этой атомарности, что подумайте - стоит ли применять. Вместе с тем ДАННАЯ модель многопоточного программирования - может использовать атомарность только для работы с переменной "z", а не с "a" и "b". В простейшем моем, сильно утрированном примере - вы всего 1 раз поставить на кол всю систему, а не 2 раза. Теперь "введите" десять потоков, которые доведут до ручки систему, если использовать "обычный" "атомарный" подход в Java.
Тем более при изменении таких нескольких переменных - помимо атомарности все равно нужно вводить синхронизацию на это место в коде, при lock-подходе.
Минусы:
1) Не возможно отменять большинство операций, связанных с I/O. Правда в некоторых реализациях транзакционной памяти применяют буферы, чтобы обойти этот момент.
2) Может быть высокий рост производительности (как и бОльшая понятность кода и более проще отладить), но это смотря сколько процессоров в вашей системе и еще некоторых факторов.
Более подробно вы можете изучить в Википедии - "Software transactional memory (English)"
Используется сокращение - STM (Software transactional memory).
Достаточно сказать, что она вошла в состав новейшего .NET 4, вполне достаточно, чтобы попробовать изучить.
Как явствует из Википедии (ссылка выше) - это модель работы с многопоточностью, применяемая часто в СУБД, которая коренным образом отличается от lock-модели.
Плюсы достаточно интересны - во-первых она более проста для понимания и использования, чем lock-модель. Во-вторых она может быть и более быстрой (не всегда, но при каких-то условиях и сильно еще зависит от конкретной реализации). В-третьих, по уверению авторов, она менее подвержена такому КРАЙНЕ нехорошему моменту в многопоточности, как инверсия приоритетов. О последнем могут не беспокоиться пользователи операционной системы реального времени QNX, а вот пользователи Windows большинства версий, Linux, FreeBSD - мягко говоря - "сосут лапу", их ОС не защищены от инверсии приоритетов в многопоточности. При определенных обстоятельствах поток с небольшим приоритетом может не получать возможность работы относительно долго, вполне достаточно для непредотвращения взрыва ядерного реактора ответственным за глушение его потоком выполнения.
Итак, чем же характеризуется модель многопоточного программирования "Транзакционная память". Модель очень проста:
1) Есть какое-то место в программе, разделяемое между несколькими потоками, какие-то данные, для краткости назовем их переменными "a" и "b".
2) Нужно обеспечить атомарность изменения переменных "a" и "b" разными потоками. Например поток 1-ый делает инкремент обеим переменным, 2-ой - декремент обеим этим переменным, при этом нужно чтобы потоки делали этим изменения последовательно, сначала один из них начал работу, закончил, только тогда второй поток может тоже начать изменять их.
3) Lock-модель делает блокировку этого места в коде. При этом только один поток работает с залоченными местом в коде, остальные потоки ждут, когда и им дадут возможность поработать с этим местом кода тоже. Транзакционная память делает иначе - она позволяет ВСЕМ получать доступ к этому месту кода. Фишка тут в следующем, - ПЕРЕД тем как начать изменять (или просто считывать) переменные "a" и "b" - выполняющийся поток увеличивает значение или изменяет флаг какой-то особой переменной, выделенной для этой цели - назовем эту переменную как "z". Смотрите - поток изменяет флаг в "z", после этого работает с участком кода, где переменные "a" и "b". ПОСЛЕ этого, как данный поток внес изменения в "a" и "b" - он проверяет значение флага в переменной "z". Если значение флага в "z" не изменилось, значит никто не "покусился" за это время на переменные "a" и "b". Если изменилось, значит транзакция нарушена и, что нужно сделать в таком случае? - правильно, откат транзакции! Поток еще раз пробует поставить значение флага "z" и внести изменения в переменные "a" и "b". Все очень зависит от процессора и подсистем памяти - вполне возможно, что многие потоки получат достаточно времени, что гарантированно внести изменения в это место - и успеть поставить флаг и поменять обе переменные, пока данный поток не будет вытеснен другим потоком.
И дело вот еще в чем, про это не знает абсолютное большинство Java-программистов - вы можете затипизировать переменные "a" и "b" особыми атомарными типами, которые есть в Java. Да вот в чем незадача - атомарность эта достигается за счет полного блокирования системной шины. Ваша система может таким "колом" встать от этой атомарности, что подумайте - стоит ли применять. Вместе с тем ДАННАЯ модель многопоточного программирования - может использовать атомарность только для работы с переменной "z", а не с "a" и "b". В простейшем моем, сильно утрированном примере - вы всего 1 раз поставить на кол всю систему, а не 2 раза. Теперь "введите" десять потоков, которые доведут до ручки систему, если использовать "обычный" "атомарный" подход в Java.
Тем более при изменении таких нескольких переменных - помимо атомарности все равно нужно вводить синхронизацию на это место в коде, при lock-подходе.
Минусы:
1) Не возможно отменять большинство операций, связанных с I/O. Правда в некоторых реализациях транзакционной памяти применяют буферы, чтобы обойти этот момент.
2) Может быть высокий рост производительности (как и бОльшая понятность кода и более проще отладить), но это смотря сколько процессоров в вашей системе и еще некоторых факторов.
Более подробно вы можете изучить в Википедии - "Software transactional memory (English)"
Используется сокращение - STM (Software transactional memory).
Разбираемся с JBoss Transactions. Часть 1
Источник - ссылка 1 и ссылка 2.
JBoss Transactions, оно же JBoss Transaction Service (JBossTS) состоит из:
1) Arjuna Core - это сам транзакционный движок (engine). Разработан компанией Arjuna Technologies. Входит в решения от HP (HP-TS, HP-WST и HP-MS), а так же входит в, как написано - ATS, AWST, AMS и новый AXTS.
2) Transactional Objects - это EJB-подобные объекты, адаптированные под движок п.1.
JBossTS (это все это) входит в состав сервера приложений JBoss AS, так же может входить в состав других контейнеров, потребляет мало ресурсов (а значит пригоден и для встраиваемых устройства), отличная многопоточность, в описании упоминаются OASIS BTP, WS-CAF (или WS-T) транзакционные модели.
Во второй части нас ждет описание - какие возможности, какую функциональность мы получаем от всего этого.
JBoss Transactions, оно же JBoss Transaction Service (JBossTS) состоит из:
1) Arjuna Core - это сам транзакционный движок (engine). Разработан компанией Arjuna Technologies. Входит в решения от HP (HP-TS, HP-WST и HP-MS), а так же входит в, как написано - ATS, AWST, AMS и новый AXTS.
2) Transactional Objects - это EJB-подобные объекты, адаптированные под движок п.1.
JBossTS (это все это) входит в состав сервера приложений JBoss AS, так же может входить в состав других контейнеров, потребляет мало ресурсов (а значит пригоден и для встраиваемых устройства), отличная многопоточность, в описании упоминаются OASIS BTP, WS-CAF (или WS-T) транзакционные модели.
Во второй части нас ждет описание - какие возможности, какую функциональность мы получаем от всего этого.
Планируется цикл статей "Разбираемся с..."
Планирую написать серию небольших статей, в которых будет аналитика по каким-то решениям от JBoss/Red Hat. Какой в этом интерес?
1) Прежде всего, как показывает просмотр документации и обсуждений в Интернете - решения от JBoss за свою основу берут всем известные открытые спецификации и фреймворки, например это JSRs (JEE), Apache, OASIS. При чем в некоторых случаях решения от JBoss - на нижнем уровне соответствуют указанным JSRs, а решения от Apache - соответствуют гораздо хуже.
2) Решения от JBoss - зачастую более "гладкие", удобные в использовании.
3) Решения от JBoss - бесплатны и это open source. Если вы захотите платную поддержку и еще более расширенный и удобный функционал, то при таком желании вы всегда можете перейти на аналогичные платные решения от Red Hat. При этом вам не придется переучиваться.
4) Альтернативы - от Sun это зачастую не очень прожевываемое (я про их сервер приложений), а решения от Oracle и IBM - довольно дороги (мягко говоря). Да, не все тут "черное - черное", а "белое - белое", и все же, обобщая, лично мне кажется что все так.
5) Как-то мне сказали, что Apache - всегда, вроде как будет, в решения от JBoss - они как? Товарищи, решениям от JBoss уже по 15-20 лет, что вы. Финансовый кризис компания Red Hat пережила хорошо, часть решений от JBoss/Red Hat вошли в новые JSRs, а что будет через 30 лет - давайте не будем загадывать. Вы сейчас можете применять JDK 1.2? Доводы еще остались? Излагайте, внимательно слушаю вас. :)
От себя скажу, что обсуждаемое мною - будет, как я понимаю, т.е. не я автор этих решений и с большинством из них не очень то и знаком. Одной из целью обсуждений - будет попытка разобраться самому.
1) Прежде всего, как показывает просмотр документации и обсуждений в Интернете - решения от JBoss за свою основу берут всем известные открытые спецификации и фреймворки, например это JSRs (JEE), Apache, OASIS. При чем в некоторых случаях решения от JBoss - на нижнем уровне соответствуют указанным JSRs, а решения от Apache - соответствуют гораздо хуже.
2) Решения от JBoss - зачастую более "гладкие", удобные в использовании.
3) Решения от JBoss - бесплатны и это open source. Если вы захотите платную поддержку и еще более расширенный и удобный функционал, то при таком желании вы всегда можете перейти на аналогичные платные решения от Red Hat. При этом вам не придется переучиваться.
4) Альтернативы - от Sun это зачастую не очень прожевываемое (я про их сервер приложений), а решения от Oracle и IBM - довольно дороги (мягко говоря). Да, не все тут "черное - черное", а "белое - белое", и все же, обобщая, лично мне кажется что все так.
5) Как-то мне сказали, что Apache - всегда, вроде как будет, в решения от JBoss - они как? Товарищи, решениям от JBoss уже по 15-20 лет, что вы. Финансовый кризис компания Red Hat пережила хорошо, часть решений от JBoss/Red Hat вошли в новые JSRs, а что будет через 30 лет - давайте не будем загадывать. Вы сейчас можете применять JDK 1.2? Доводы еще остались? Излагайте, внимательно слушаю вас. :)
От себя скажу, что обсуждаемое мною - будет, как я понимаю, т.е. не я автор этих решений и с большинством из них не очень то и знаком. Одной из целью обсуждений - будет попытка разобраться самому.
Подписаться на:
Сообщения (Atom)