Ежедневно мутя с потоками, такая радость, их заменить на процессы с общей памятью, не так просто приходит в голову. Лучше сразу убиццо апстену. Деформация такая. Тупеем потихоньку.StrangerR wrote: Да нет, тред легко заменяется процессами с общей памятью. По сути это почти одно и тоже, с некоторыми отличиями (у тредов общего больше чем просто общая память данных при самостоятельной памяти стеков).
Это потому, что во-первых, MS SQL и так работал с "настоящими" threads, как если бы они были почти "fibers", во-вторых, они имеют смысл для очень высокопроизводительных сценариев (много процессоров, много их утилизации). Ну и таки да, ошибки были - и в MS SQL и в библиотеке файберов в ОС.Dmitry67 wrote:Кстати, когда то попробовал в ms sql "fibers". Разницы не почувствовал, разве что перестали работать distributed transactions
Это уже давно не совсем так у Оракла.Dmitry67 wrote:Ну вот Оракл по моему написан большими процессами с общей памятью.
Yes, indeed.Dmitry67 wrote:Угу, но начинали они по моему с этого.
Мне об этом ничего не известно. Поделитесь откуда дровишки.Dmitry67 wrote:....
А сейчас threads на z/OS конечно есть, в виртуалках
...
На МФ для этого используется два механизма - создание такого же unit of work как и основная задача (TCB), и SRB, о котором я уже говорил (не совсем корретно честно говоря). SRB - это облегченный вариант TCB с некоторыми ограничениями (например в них не допускаются операции ввода выводы и обращения к супервизору т.е. SVC (API по вашему). Т.е. строго говоря SRB не есть средство доступное бизнес программистам и вряд ли доступно на языках высокого уровня. Это среддтво для системного програмирования только. Таким образом на МФ есть один единый способ распаллеливания задачи - это создание новых задач, с точки зрения системы таких же как и основная.Multithreading is the ability for a program to multitask within itself. The program can split itself into
separate "threads" of execution that also seem to run concurrently. This concept might at first seem
barely useful, but it turns out that programs can use multithreading to perform lengthy jobs in the
background without requiring the user to take an extended break away from their machines. Of course,
sometimes this may not be desired: an excuse to take a journey to the watercooler or refrigerator is
often welcome! But the user should always be able to do something on the machine, even when it's
busy doing something else.
Dmitry67 wrote:Ну так в виртуалках у вас юникс, правильно?
Это до сих пор почти так. А начиналось с _только так_.tengiz wrote:Это уже давно не совсем так у Оракла.Dmitry67 wrote:Ну вот Оракл по моему написан большими процессами с общей памятью.
А там же нет ассемблера а только языки уровня жавы и выше (по сути Эль 76 - смесь Алгола 68 и Ады). Плюс теги. Вполне там удобно все могло программироваться, как я понимаю.Dmitry67 wrote:Хотелось бы вернуться к нашим баранам. Как я говорил, в бэсм была очень неудобная работа со строками. А как в эльбрусе? Там ведь тоже только огромные слова адресуются вроде бы
Code: Select all
для i от 2 до n
цикл
ф64 x;
x := a[0] := a[i];
до найденменьшеx
для j от i - 1 вниздо 0
цикл
если a[j] <= x то найденменьшеx!(j)
иначе a[j+1] := a[j]
всё
повторить
при
найденменьшеx(k): a[k+1] := x
всёсит
повторитьЧувствуется, что писалось сразу после _замутнения потоков_.Medium-rare wrote:Ежедневно мутя с потоками, такая радость, их заменить на процессы с общей памятью, не так просто приходит в голову. Лучше сразу убиццо апстену. Деформация такая. Тупеем потихоньку.StrangerR wrote: Да нет, тред легко заменяется процессами с общей памятью. По сути это почти одно и тоже, с некоторыми отличиями (у тредов общего больше чем просто общая память данных при самостоятельной памяти стеков).
Потому что это абсолютно независимые понятия. Тред на процессорах - означает что там можно создать несколько КОНТЕКСТОВ и процессор будет делать вид, что у него больше коров чем на самом деле. Экономия будет на переключении контекстов а возможно еще на том что какие то элементы процессора могут раздельно использоваться разными тредами.zVlad wrote:А почему же тогда в списке параметров неких процессоров приводится число этих самых threads?Palych wrote:zVlad, по-моему Вы что-то путаете.
Threads работают без аппаратной поддержки где угодно.
Это всего лишь абстракция...
Это не так точнее совсем не такПереключение между "процессами" и "потоками" (или "нитями" или "легкими процессами") стоит примерно одинаково.
Спасибо. Я тоже склонялся к токому же обьяснению. Теперь все вроде сходится - просто использовали одно слово в разных фирмах вложив в него разный смысл. А интерeсно все таки - ОС в курсе threads процессора или это ей не доступно знать и использовать? Логично было бы предположить что это недоступно ОС хотя ....StrangerR wrote:Потому что это абсолютно независимые понятия. Тред на процессорах - означает что там можно создать несколько КОНТЕКСТОВ и процессор будет делать вид, что у него больше коров чем на самом деле. Экономия будет на переключении контекстов а возможно еще на том что какие то элементы процессора могут раздельно использоваться разными тредами.zVlad wrote:....
А почему же тогда в списке параметров неких процессоров приводится число этих самых threads?
....
Никакой связи между тредами в корове и тредами в процессе нету, кроме некоторой схожести части понятий.
Там основной выигрыш через "memory bank interleaving": если у вас - несколько "банков памяти".StrangerR wrote:Переключение треда
- взять регистры для процесса, выставить новое положение стека
- запуститься
Намного меньше так как не меняется меппинг памяти, права и внешние объекты.
Видит операционка иx ("это - доступно ОС"). Посмотрите "перформанс монитор" в Виндоус xоть. Если тредов больше чем коре - она за каждым "следит" по отдельности (каждый "тред" для Виндоус - логический процессор, "внешне не отличимый" от физического коре - который тоже логический процессор если число тредов равно числу коре).zVlad wrote: А интерeсно все таки - ОС в курсе threads процессора или это ей не доступно знать и использовать? Логично было бы предположить что это недоступно ОС хотя ....
Я полагаю, Ваши сведения устарели для популярных цпу и ОС. На современных процессорах "mapping памяти" переключается тривиально (загрузка нескольких регистров, самое дорогое при этом - некоторые внутренние процессорные кеши обнуляются, но на "совсем современных" процессорах даже это уже незаметно), права доступа у тредов даже в одном процессе бывают разные, кроме того, эти самые права и контексты внешних объектов в современных популярных ОС - это всего лишь данные в памяти - при переключении маппинга памяти автоматически все переключается.StrangerR wrote:Это не так точнее совсем не такПереключение между "процессами" и "потоками" (или "нитями" или "легкими процессами") стоит примерно одинаково.
Переключение процесса
- полностью поменять меппинг памяти (ну да, в новом часть может совпадать если там шеред сторейдж)
- поменять контекст прав доступа
- поменять контекст внешних объектов (fd и прочего)
- взять регистры и прочее для процесса включая положение стека
- запуститься
Переключение треда
- взять регистры для процесса, выставить новое положение стека
- запуститься
Намного меньше так как не меняется меппинг памяти, права и внешние объекты.
Конечно, когда в те времена, когда Оракл работала на всем, кроме кирогаза (десятки прогаммно-аппаратных платформ) было не до изысков. А вот когда его портировали на Wintel, удобство многопотоковой архитектуры тут же оказалось к месту. Поэтому как минимум на Wintel Оракл - многопотоковый, хотя и большие куски изначальной архитектуры с несколькими процессами разного назначения до сих пор имеются, хотя за что у них там в самых последних версиях я уже не в курсе.StrangerR wrote:Это до сих пор почти так. А начиналось с _только так_.tengiz wrote:Это уже давно не совсем так у Оракла.
ерунду рассказываете. когда портировали на винду выяснилось, что у винды переключение процессов работает чудовищно медленно, пришлось переделывать на тхреды, что бы хоть как-то конкурировать с другими. под линуксом и соляркой на интеле оставили процессы. только сейчас, в дань моде, в версии 12с сделали параметер threaded_execution, который переключает на тхреды на unix/linux платформах, но кроме неудобства никто разницы не видит.tengiz wrote:Конечно, когда в те времена, когда Оракл работала на всем, кроме кирогаза (десятки прогаммно-аппаратных платформ) было не до изысков. А вот когда его портировали на Wintel, удобство многопотоковой архитектуры тут же оказалось к месту. Поэтому как минимум на Wintel Оракл - многопотоковый, хотя и большие куски изначальной архитектуры с несколькими процессами разного назначения до сих пор имеются, хотя за что у них там в самых последних версиях я уже не в курсе.
Вы что-то путаете. Нет никакой заметной разницы при переключении потоков или процессов на Wintel и никогда не было.iDesperado wrote:ерунду рассказываете. когда портировали на винду выяснилось, что у винды переключение процессов работает чудовищно медленно, пришлось переделывать на тхреды, что бы хоть как-то конкурировать с другими. под линуксом и соляркой на интеле оставили процессы. только сейчас, в дань моде, в версии 12с сделали параметер threaded_execution, который переключает на тхреды на unix/linux платформах, но кроме неудобства никто разницы не видит.
Во всяком случае какая-то зависимость от ОС - точно есть. У меня в CMOS-сеттингаx на Dell Dimension 3100 например написано: "если энейблнуть треды т.е. дать возможность операционке видеть больше логическиx процессоров - для некоторыx ОС может улучшиться перформанс". Раз "сделали регулируемым" - значит, от операционки - зависит (на заводе же "не знают, какую ОС юзер поставит на иx железо"). Логично? Скриншот сделать не могу: в BIOS же Принт-скрин, ессно, не работает.tengiz wrote:Вы что-то путаете. Нет никакой заметной разницы при переключении потоков или процессов на Wintel и никогда не было.iDesperado wrote:ерунду рассказываете. когда портировали на винду выяснилось, что у винды переключение процессов работает чудовищно медленно, пришлось переделывать на тхреды, что бы хоть как-то конкурировать с другими. под линуксом и соляркой на интеле оставили процессы. только сейчас, в дань моде, в версии 12с сделали параметер threaded_execution, который переключает на тхреды на unix/linux платформах, но кроме неудобства никто разницы не видит.