Pull to refresh
1
0

Пользователь

Send message

Про поезд вы неправы. Тормозная магистраль у поезда одна. Нет никакой отдельной "магистрали управления тормозами". Если машинист снижает давление в магистрали - срабатывают тормоза. Если срывают стоп-кран - снижается давление в магистрали и срабатывают тормоза. Если тормозная магистраль теряет герметичность (например оторвало рукав) - срабатывают тормоза. Воздух для торможения при этом берется из запасного резервуара, который есть в каждом вагоне, и заряжается из тормозной магистрали.

Допустим, у нас есть два бинарных файла, один для Linux, другой для Windows.
Код будет одинаковый. Разным будет способ вызова ОС. А вызывать придется часто — user mode это такая песочница, где без помощи ОС можно разве что чисто вычислительные задачи выполнять.
Но фактически программа выполняется через ОС, то
есть выполняется как бы некий двоичный код, который понимает ОС, а ОС
вызывает уже команды CPU.
Все почти так и есть. Только код (точнее его разрешенное в user mode подмножество) может выполняться на CPU сам по себе. Но, например, любое общение с периферийными устройствами (экран, клавиатура, мышь, диски, сеть, все USB устройства и т.д.) требует обращения к особым ячейкам памяти — регистрам. А в user mode это запрещено на аппаратном уровне. Т.е. вы делаете вызовы к ОС в формате который понимает ОС, а уже ОС пишет/читает регистры и делает много чего другого.

Пример действий, требующих вызова ОС:
  • Выделение памяти: да, у вас есть обычно от 4Гб адресного пространства, но это как разреженный массив — реальной памяти там может быть всего мегабайт 10. А попытка обращения за пределы этих 10Мб вызовет исключение — будет вызван код ОС.
  • Чтение/запись файла: нет ни ассемблерных команд, ни доступных вам ячеек в памяти, которые могут вызвать операции чтения или записи. Вы подготавливаете запрос
  • Вывод на экран (текста в консольном приложении, трехмерной графики).
  • Получение сообщений от мыши, клавиатуры, джойстика.
  • Любые операции с потоками (запуск, останов, пауза).
  • Мьютексы, фьютексы, семафоры, критические секции.

Под 32х и 64х-битный режим машинный код будет разным и на одной ОС.

Если я вас правильно понял, неправильный у вас инстинкт на ручке выработан.
Сначала инстинктивно жмем на тормоз. И только потом, в конце торможения, выжимаем сцепление чтобы не заглохнуть. Торможение с включенной передачей более эффективно и безопасно.
У вас ошибка в первом запросе с UNION — case2 кроме ожидаемого результата добавляет непересекающиеся диапазоны слева, а case3 — справа.
Должно быть так:
...  
   union all
   select p.start_time, s.stop_time -- case #2
     from periods p, schedule s
    where p.start_time >= s.start_time      
      and p.stop_time  > s.stop_time
      and p.start_time <  s.stop_time
   union all
   select s.start_time, p.stop_time -- case #3
   from periods p, schedule s
   where p.start_time <= s.start_time
     and p.stop_time  <  s.stop_time
     and p.stop_time  >  s.start_time
   union all
...

И есть решение проще и универсальнее:
SELECT 
  GREATEST(s.start_time,p.start_time) as start_time, 
  LEAST(s.stop_time,p.stop_time) as stop_time 
FROM 
  periods p, schedule s
WHERE 
  not(( s.stop_time < p.start_time) or (s.start_time > p.stop_time))

Логика запроса в том что выбираются непересекающиеся множества справа и слева. Теперь если инвертируем условие — получаем остальные записи, т.е. все пересекающиеся.
Если таблицы не будут временными - можно создать индекс:
  CREATE INDEX idx_sсhedule_time ON schedule (start_time, stop_time); 

explain (analyze) ...
В таблице periods 4 записи, в таблице schedule 496 записей (генератор из статьи за 2 года).

Nested Loop (cost=0.27..30.23 rows=220 width=16) (actual time=0.049..0.085 rows=18 loops=1)
-> Seq Scan on periods p (cost=0.00..1.04 rows=4 width=16) (actual time=0.019..0.019 rows=4 loops=1)
-> Index Only Scan using idx_schedule_time on schedule s (cost=0.27..6.47 rows=55 width=16) (actual time=0.014..0.014 rows=5 loops=4)
Index Cond: ((start_time <= p.stop_time) AND (stop_time >= p.start_time))
Heap Fetches: 0
Planning Time: 0.264 ms
Execution Time: 0.115 ms

Вариант с tsrange индексы у меня не использует (попробовал разные варианты, возможно не те создавал).
Несколько неточностей:
Хотя там есть параметр Junction-to-Foot, допустим, нам интересно именно тепловое сопротивление Junction-to-Ambient, а оно приведено только для времени менее 10 секунд.
Там по сноске написано, что тепловое сопротивление для расчетов DC составляет 80°C/W («c. Maximum under Steady State conditions is 80°C/W»)
Из графика видно, что после 1000 секунд, значительный рост теплового сопротивления прекращается, значит для постоянного тока можно ориентироваться на это значение, итого 80 °C/Вт – тепловое сопротивление Junction-to-Ambient.
Тепловое сопротивление это константа. На графике приведен рост разности температур Junction-Ambient с течением времени. В установившемся режиме эта разность численно равна тепловому сопротивлению, т.к. используется источник тепла мощностью 1Вт. График построен по математической модели и приведен с целью проиллюстрировать равнозначность последовательной (Partial-fraction/Tank/Foster/Pi) и параллельной (Continued-fraction/Filter/Cauer/T-model/Ladder) эквивалентных моделей теплового сопротивления. Более низкие значения «тепловых сопротивлений» отражают тепловую инерцию модели. При выполнении некоторых допущений эти значения можно использовать в расчетах, забыв про теплоемкость (которая и является причиной «роста теплового сопротивления» на графике).
Для того же SQM50P03-07 в даташите есть SOA, однако, как можно заметить, она приведена для окружающей среды, температурой в 25 °C (не наш случай)
В данном случае прямо на графике указана температура корпуса Tc=25°C.
Инженер может при столкновении с проблемой придумать новые пути решения. И это для него не геройство, а будни.

Задача «чистого» инженера — решить поставленную задачу, комбинируя известные и хорошо опробованные технологии. Как у архитектора — построить дом с заданными параметрами, используя материалы с известными характеристиками. Сложность в том чтобы правильно согласовать все между собой, выполнив все требования.
А изучение чего-то принципиально нового — скорее задача для научного сотрудника. Конечно, инженеры часто занимаются и НИОКР — не сказал бы что это плохо. Но в некоторых отраслях «инициатива» (стремление использовать что-то новое, нестандартное, свое) инженера не то что нежелательна, а даже наказуема.
Интересная классификация. Мне кажется разделение здесь основано на мотивации:
Линейный — остаться в зоне комфорта минимальными усилиями, интроверт.
РокСтар — удовлетворить собственное любопытство в сфере, профильной деятельности компании.
Делец — максимальная выгода минимальными усилиями.
Пассажир — остаться в зоне комфорта минимальными усилиями, экстраверт.

Поясню про «зону комфорта». В отношении работы, оставаться в зоне комфорта — значит выполнять возложенные на тебя обязательства и получать за это материальные и моральные/репутационные плюшки.
Линейный выполняет обязательства (выполняет работу в срок, учит новые технологии), не требуя взамен ничего сверх положенного и стараясь не перетруждаться.
Пассажир идет на диалог, стремясь во-первых получить больше нематериальных плюшек (ему общение в радость), а во-вторых уменьшить обязательства (уболтать того, кто эти обязательства определяет либо переложить часть работы на других).
или Стив Возняк.
Пожалуй, самый известный «пассажир» — Стив Джобс.
Пассажир и делец.

Information

Rating
Does not participate
Date of birth
Registered
Activity