Просмотр сообщений
Страниц: [1] 2 3 ... 42
1  Разработка / Программирование под QNX / Re: функция shutdown_system() : Июля 10, 2017, 12:42:52 pm
Да я обычно на Си и работаю.
К сожалению, не в этом проекте.

Можно переименовать поле, например, в class1.
Но не хочется править системные h-файлы.

Меня смущает, что разработчики так неаккуратно выбрали идентификатор.
как вариант - сделайте отдельный C-шный файл, в котором будет включаться этот заголовочный файл и в котором будет Ваша функция, которая вызывает shutdown_system().
2  Общее / Общение / Re: Система контроля версий Git : Июня 26, 2017, 09:25:49 pm
А в моём примере с формулой мы с Васей не пересеклись по координатам символов. Следовательно, я так понимаю, что в формуле поменяется и знак (от Васи) и имя коэффициента (от меня).
В svn сравнение идёт строками, так-что такой вариант Вам не грозит.
3  Общее / Общение / Re: Система контроля версий Git : Июня 26, 2017, 05:55:58 pm
А как в subversion подобные вопросы решаются? Smiley Суть-то у всех этих систем одна и та же.
Хорошо решаются.

Для того, чтобы записать в репозиторий сначала надо забрать изменения, сделанные после того, как Вы последний раз их забирали из репозитория. Вам система контроля версий не даст записать свои локальные изменения из рабочей копии пока Вы не обновите её до того, что есть в репозитории. Если Вы с гипотетическим Васей редактировали разные файлы или даже один и тот-же файл, но в разных, не пересекающихся местах, то система контроля версий автоматически объединит Ваши изменения. Если Вы редактировали одно и то же место, то svn даст возможность выбрать или Вашу правку, или Васину, или вообще написать свой вариант.
4  Общее / Общение / Re: Система контроля версий Git : Июня 26, 2017, 12:59:35 pm
К сожалению по Git подсказать не могу, у нас используется Subversion так-же известный как svn. Они, в принципе, похожи, но в многих практических вопросах могут отличаться, так-что я не уверен, насколько опыт работы с svn может быть применим к Git.
5  Общее / Проект QNX.ORG.RU / Re: Для новых пользователей, кто пытался зарегестрироваться : Мая 03, 2017, 03:42:23 pm
Аналогичная ситуация. Атака продолжается уже несколько месяцев. Все ожидающие активацию пользователи были удалены. Если кто, вдруг, оказался не ботом, просьба попробовать заново зарегистрироваться попозже. При регистрации просьба в подписи временно указывать ключевое слово "qnx.org.ru". Все пользователи пытающие зарегистрироваться без этого слова будут блокироваться. После написания пары осмысленных сообщений и выяснения того, что пользователь не является ботом, подпись можно будет изменить. Просим извинения за временные неудобства.
6  Разработка / Программирование под QNX / Re: Работа через USB с FlirOne Gen 2 : Марта 20, 2017, 08:32:07 pm
Цитировать
из того, что было написано по той ссылке - барьерами памяти является любой вызов функции, а то, что при этом pthread_mutex_*(), имхо, это дело десятое.

Ну прочтите ж вы ссылку, что я давал! Там написано, какие вообще эти барьеры бывают. Мютекс - это барьер захвата/освобождения.

Во-первых, статью я давал для показа, что из себя представляет мютекс, а не volatile. А во-вторых, Volatile тоже является барьером памяти. Просто вбейте в гугле "volatile барьер памяти" и всё найдётся сразу же.
Например, тут пишут, что volatile не является барьером памяти. Эта Функциональность, как и сказал lastcross была привязана только в майкрософтовском компиляторе, и очень даже нестандартна.

Вот и в Wikipedia пишут - "The keyword volatile does not guarantee a memory barrier to enforce cache-consistency.". Кстати, для 86 архитектуры пришлось придумывать команду mfence, чтобы гарантировать барьеры памяти на уровне команд, а в компиляторах сначала приходилось обходиться разными asm volatile("" ::: "memory"), а начиная с C11/C++11 - более цивилизовано - функции atomic_signal_fence(memory_order_acq_rel) и atomic_thread_fence(memory_order_acq_rel) - см здесь.

А вызовы функций, думаю любых, командой call, барьером являются, иначе-бы могли происходить такие интересные вещи как вызов функции до вычисления всех входных её аргументов.
7  Разработка / Программирование под QNX / Re: Работа через USB с FlirOne Gen 2 : Марта 20, 2017, 03:06:45 pm
Цитировать
Сорри, не совсем понял, что должен был выкинуть компилятор?

Да очень простую вещь:

bool done=false;

while(1)
{
 if (done==true) break;
}

Компилятор выбросит if (done==true) break; так как он видит, что done не меняется. При этом если done будет volatile, то компилятор эту строчку не выбросит. Либо если этот контроль будет внутри заблокированного мютекса.

Цитировать
По-моему тут есть объяснение почему в обвёртке

Вот, я и написал, что мютекс - это барьер памяти. Это совершенно особая вещь для компилятора.
из того, что было написано по той ссылке - барьерами памяти является любой вызов функции, а то, что при этом pthread_mutex_*(), имхо, это дело десятое. Например Вы можете сделать свои функции обвёртки над мутексами и про то, что это были pthread_mutex_*() узнает только линковщик, а если подгрузить библиотеку динамически dlopen()/dladdr(), то и он не узнает.
8  Разработка / Программирование под QNX / Re: Работа через USB с FlirOne Gen 2 : Марта 20, 2017, 12:15:24 pm
Цитировать
А механизмы которые полностью удовлетворяют мультипоточности - не требуют volatile
На микроконтроллерах - требуют. Вы ограничиваетесь исключительно теми платформами, которые ваш любимый Си++ 11 поддерживают и отчего-то полагаете, что так везде? Ну так нет.
Сорри, что вмешиваюсь - но микроконтроллеры это своя, очень специфичная область, в которой очень много ньюансов. По моему мнению, volatile, по крайней мере на этапе изобретения, был придуман вовсе не для многопоточности и синхронизации доступа, а для обращения к устройствам, отображенным на память. Для этого он вполне себе подходит, для других вещей, имхо - не очень, если не сказать хуже.

Цитировать
Я про то что мьютекс - является объектом ядра. Операции над ним - "атомарны" и гарантировано это самим ядром (как правило ядро - это ОС). Про контроллеры я вам ничего не скажу.

А как по-вашему компилятор соображает, что переменная внутри Lock() - Unlock() мютекса и внешняя переменная не volatile типа могут быть связаны? Сам мютекс, как объект, ничего не знает о защищаемых переменных.  
Пример:
Код: (C++)
bool Done=false;

pthread_mutex_t mutex_ID;

//первый поток
void Thread_1(void)
{
 sleep(10);
 pthread_mutex_lock(&mutex_ID);//блокируем мьютекс
 Done=true;
 pthread_mutex_unlock(&mutex_ID);//разблокируем мьютекс
}

//второй поток
void Thread_2(void)
{
 pthread_mutex_lock(&mutex_ID);//блокируем мьютекс
 Done=false;
 pthread_mutex_unlock(&mutex_ID);//разблокируем мьютекс
 sleep(1);
 while(1)
 {
  pthread_mutex_lock(&mutex_ID);//блокируем мьютекс
  if (Done==true) break;
  pthread_mutex_unlock(&mutex_ID);//разблокируем мьютекс
 }
 pthread_mutex_unlock(&mutex_ID);//разблокируем мьютекс
}

В этом примере if (Done==true) break; компилятор, основываясь только на мютексе, запросто мог бы выкинуть эту строчку. А что? Он ничего не знает о том, что Done способно измениться внезапно. Так мютекс не просто объект ядра, мютекс реализует вот какой механизм:

acquire_barrier(); - барьер захвата
if (Done==true) break;
release_barrier(); - барьер освобождения

Подробнее тут: http://scrutator.me/post/2015/05/16/memory_barriers.aspx
И вот именно поэтому и не нужен volatile внутри мютекса. И компилятор (а не только ядро) всё это знают.
Сорри, не совсем понял, что должен был выкинуть компилятор?

Ну и кроме того - при обсуждении необходимо смотреть стандарты. Функции семейства pthread* покрывает не стандарт C++, и даже не стандарт C, а POSIX - видимо туда и надо смотреть.

Но когда вы начнёте писать для микроконтроллеров, там не будет барьеров и всё это вы будете делать сами с помощью этого самого volatile. Поясню примером.
Допустим, вы в прерывании меняете значение Done. А атомарность обеспечите sei и cli. Всё, что между ними - атомарно (прерывание запрещено). Но компилятор похерит if (Done==true) break; с вероятностью 100%.
По-моему тут есть объяснение почему в обвёртке pthread_mutex_*() всё работает, а в sie/cli - нет. "Any function whose definition is not available in this translation unit (and is not intrinsic) is a compiler memory barrier. pthread_mutex_lock, pthread_mutex_unlock, pthread_create also issue a hardware memory barrier to prevent the CPU from reordering reads and writes." sie/cli - скорее всего реализованы или через inline-ассемблер, или те самые intrinsic-и, а pthread_mutex_lock()/pthread_mutex_unlock() - через внешние, для данного модуля, библиотеки.
9  Разработка / Программирование под QNX / Re: Выход из бесконечного цикла while по нажатию любой клавиши : Января 17, 2017, 10:57:28 am
День добрый!
Собственно вопрос в теме. К сожалению, здесь нет библиотеки conio.h и kbhit.
Попробуйте поиск по форуму. Например, нашлось вот такое и такое.
10  Разработка / Программирование под QNX 4.x / Re: KEEPALIVE в QNX4.25 : Января 16, 2017, 09:27:07 am
Цитировать
Не уверен. Возможно какие-то настройки можно сделать через sysctl, если у Вас версия реализации стека протоколов TCPIP 5.0, а не 4.25.
А если версия стека протоколов TCPIP 4.25?
Там, насколько я помню, sysctl нет совсем.
11  Разработка / Программирование под QNX 4.x / Re: KEEPALIVE в QNX4.25 : Января 13, 2017, 05:53:50 pm
Для обнаружения физического разрыва соединения предполагается использовать опцию SO_KEEPALIVE.
Включение и изменение периода неактивности (по умолчанию 2 часа) делается следующим образом:

Код: (C)
int on = 1;  struct timeval tval = { 20, 0 };

// Включение
setsockopt(Sock, SOL_SOCKET,  SO_KEEPALIVE,  (void*)&on,   sizeof(on));
// Изменение периода неактивности
setsockopt(Sock, IPPROTO_TCP, TCP_KEEPALIVE, (void*)&tval, sizeof(tval));
К сожалению уже довольно давно не занимаюсь QNX, но вроде TCP_KEEPALIVE требовало int*, а не struct timeval*.

Подскажите, есть ли возможность изменить количество пакетов (по умолчанию - 8 ) и таймаут между ними (по умолчанию 75 сек)?
Не уверен. Возможно какие-то настройки можно сделать через sysctl, если у Вас версия реализации стека протоколов TCPIP 5.0, а не 4.25.
12  Разработка / Программирование под QNX / Re: TCP/IP Серверы, клиент и утилита on : Ноября 28, 2016, 10:54:02 am
on -f A2 cl &
не помогает?
13  Разработка / Программирование под QNX / Re: Смена пароля из программы : Июля 20, 2016, 11:44:52 am
В QNX 6.5.0 (КПДА) после логина запускается прикладная программа на Qt 4.8.5.
Необходимо иметь возможность изменять пароль из программы или из скрипта.

Проблема в том, что passwd использует не stdin и stdout. Перенаправить ввод не удается.

Что подскажете?
Как вариант - попробовать запустить passwd в псевдотерминале - см forkpty(), и через полученный дескриптор master-side pty передавать ему новые пароли.
14  Разработка / Программирование под QNX 4.x / Re: QNX4.25 background color in pterm : Мая 27, 2016, 06:18:39 pm
Хотелось бы узнать по подробнее применительно к QNX.
Пробовал
Код: (C)
printf("\x1b[31m hello");
выводит
Цитировать
31m hello
или так
Код:
echo -en "\e[33;44m"
не работает

К сожалению давно уже не работаю с QNX4. Возможно у Вас в pterm-е включена эмуляция терминала QNX вместо ANSI? Как настроить pterm можно посмотреть здесь.
А тут советуют использовать вместо 0x1b  использовать ESC-код 0x9b. Ну и плюс какие-то немного другие коды используют для переключения цветов. Правда не понятно, для какого pterm-а, того, который в Photon 1.1x(QNX4), или того, который в Photon 2.0(QNX6).
15  Разработка / Программирование под QNX 4.x / Re: QNX4.25 background color in pterm : Мая 27, 2016, 09:53:22 am
Здравствуйте! Smiley

Подскажите команды, как изменить цвет шрифта и фона в консоли ksh
в сценарии?

Спасибо!
А стандартные ANSI ESC-коды не работают?
Страниц: [1] 2 3 ... 42