Ptr place nissan что значит?

4. Формирование указателей PTR. Технологии SDH последнего поколения

4.1. Указатели административных блоков AU-n

4.2. Указатель транспортного блока TU-3

4.3. Указатель транспортного блока TU-12

4.1. Указатели административных блоков AU-n

Указатели AU-n подразделяются на AU-3 и AU-4. Рассмотрим указатель PTR AU-4, который чаще всего применяется для передачи. Его структура представлена на рисунке 1.40. Указатель AU-4 представлен байтами Н1, Н2.

Флаг новых данных NDF (New Data Flag) может иметь два состояния: 1001 и 0110. Первое состояние указывает на возможность изменения указателя. Второе состояние указывает на невозможность изменения указателя. Из пяти бит D или < минимум три бита должны приниматься с инверсией, т.е. с противоположным состоянием в случае подстройки указателя. Биты SS имеют состояние "10" для AU-4, AU-4-Xc, AU-3. В случае применения сцепления (последовательного или виртуального) значения бит SS могут быть изменены, что в настоящее время не специфицируется.

Рисунок 1.40. Структура указателя PTR AU-4

N – биты флага новых данных NDF; S – биты идентификатора типа AU-n; I – биты сообщения об увеличении значения PTR на единицу; D – биты сообщения об уменьшении значения PTR на единицу

Процедуры согласования скоростей в AU-4 необходимы для компенсации изменения фазы VC-4 по отношению к AU-4, что обусловлено различием тактовых частот VC-4 и AU-4, образующихся по различным причинам (изменение длины пути, дрейф частот задающих генераторов и т.д.). Согласование скоростей связано с изменением значений указателей PTR, которые могут возрастать или уменьшаться на единицу. На рисунках 1.42 и 1.43 демонстрируются процедуры изменений указателей при подстройке под фазу VC-4.

Рисунок 1.41. Адресуемое пространство указателя PTR AU-4 (0…782)

1* – байты с единичным заполнением (11111111); Y – байты с заполнением 1001SS11, S-биты не определенные по назначению

Положительное согласование происходит в случае, если частота загрузки VC-4 ниже частоты AU-4. При этом согласовании скоростей байты триады «0» сдвигаются на одну триаду вправо в третьем цикле согласования, а в 4-ом цикле согласования значение PTR AU-4 увеличивается на «1».

Отрицательное согласование происходит в случае, если частота загрузки VC-4 выше частоты AU-4. При этом согласовании скоростей байты триады «0» сдвигаются на одну триаду влево в третьем цикле согласования, а в 4-ом цикле согласования значение PTR AU-4 уменьшается на «1».

Генерация и интерпретация указателя PTR AU-4 происходит в несколько этапов.

Генерация указателя в передатчике:

• прохождение нормальных операций обработки данных по размещению VC-4 в AU-4, значение флага новых данных NDF «0110»;

• значение указателя может преобразовываться по одной из операций, перечисленных ниже;

в случае требуемого положительного согласования скоростей VC-4 и AU-4 содержимое указателя передается с инверсией бит I и становится возможным положительное выравнивание последовательности с балластным заполнением информационной триады «0». Последовательность указателя увеличивается на «1». Если значение указателя было 782, то он обнуляется «0».

Рисунок 1.42. Положительное согласование скоростей AU-4 и VC-4

После этой операции запрещается изменение указателя (возрастание или понижение) в последующих трех циклах.

В случае требуемого отрицательного согласования скоростей VC-4 и AU-4 содержимое указателя передается с инверсией бит D и становится возможным отрицательное выравнивание последовательности с перезаписью вперед данных VC-4. Значение указателя уменьшается на «1». Если предшествующее значение указателя было «0», то становится равным «782». После этой операции защищается изменение указателя (возрастание или уменьшение) в последующих трех циклах.

Новое значение указателя сопровождается изменением флага новых данных на состояние «1001». Такой флаг передается только в первом цикле нового значения указателя. Полный цикл согласования скоростей AU-4 и VC-4 занимает время 500 мкс.

Рисунок 1.43. Отрицательное согласование скоростей AU-4 и VC-4

Интерпретация указателя в приемнике:

• нормальное прохождение операций с указателем, обозначающим начало VC-4 в цикле AU-4;

• какое-либо отклонение в последовательности значения указателя не может быть пропущено, поскольку это новый адрес на приемной стороне должен быть обработан по одной из трех операций, перечисленных ниже;

• если в значении указателя инвертированы биты, то это признак положительного согласования и последовательность PTR интерпретируется на единицу больше;

• если в значении указателя инвертированы биты D, то это признак отрицательного согласования и последовательность PTR интерпретируется на единицу меньше;

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

4.2. Указатель транспортного блока TU-3

Структура указателя PTR TU-3 аналогична структуре указателя PTR AU-4 (рисунок 1.40). При этом все биты байт Н1 и Н2 имеют одинаковое с AU-4 назначение. Принципиальные различия PTR AU-4 и TU-3 состоят в образуемом пространстве указателя и использовании в TU-3 одного байта Н3 для отрицательного согласования и байта с адресом «0» для положительного согласования (рисунок 1.44). Указатель PTR TU-3 фиксирует начало цикла загрузки VC-3 в TU-3.

Флаг новых данных и метка типа TU-3 идентичны ранее рассмотренным в AU-4. Также аналогично функционирование PTR TU-3 при отрицательном и положительном согласовании VC-3 и TU-3.

Рисунок 1.44. Адресуемое пространство TU-3

Байты Н1, Н2 – указатель PTR TU-3; байт Н3 – для отрицательного согласования скоростей; байт 0 – для положительного согласования скоростей

В случае мультиплексирования трех TU-3 в структуру VC-4 и размещение последней в AU-4 и AUG, функции указателей PTR TU-3 сохраняются без изменений (рисунок 1.45).

4.3. Указатель транспортного блока TU-12

К структуре указателя транспортного блока относятся байты V1, V2, V3, V4 (рисунок 1.46).

Структура указателя PTR TU-12 представлена на рисунке 1.47.

Функции флага новых данных NDF аналогичны ранее рассмотренным для PTR AU-4. Идентификация битами S типа TU-n соответствует: TU-11 (11); TU-12 (10); TU-2 (00).

Адресуемое пространство обозначается битами I, D PTR TU-12 и составляет 0…139 (рисунок 1.46). Это пространство начинается после байта V2. Байт 35 этого адресуемого пространства, предусмотренный после V3, обеспечивает положительное согласование скоростей TU-12 и VC-12.

Нарисунке 1.50 представлено состояние флага новых данных NDF TU-12.

Рисунок 1.46. Структура TU-12 с байтами указателя

Рисунок 1.47. Структура указателя PTR TU-12

N – биты флага новых данных; S – биты идентификаторы типа TU-n; I – биты сообщения об увеличении значения PTR на единицу; D – биты сообщения об уменьшении значения PTR на единицу. Для индикации сцепки используется состояние бит указателя – 1001SS1111111111

Рисунок 1.48. Адресуемое пространство указателя PTR TU-12

Рисунок 1.49. Пример загрузки VC-12 в TU-12

Рисунок 1.50. Состояния NDF в TU-12

Источник: https://siblec.ru/telekommunikatsii/izuchenie-voprosov-postroeniya-telekommunikatsionnykh-sistem-peredachi-sdh/tekhnologii-sdh-poslednego-pokoleniya/4-formirovanie-ukazatelej-ptr

Пять подводных камней при использовании shared_ptr

Класс shared_ptr — это удобный инструмент, который может решить множество проблем разработчика. Однако для того, чтобы не совершать ошибок, необходимо отлично знать его устройство. Надеюсь, моя статья будет полезна тем, кто только начинает работать с этим инструментом.

Я расскажу о следующем:

• что такое перекрестные ссылки;
• чем опасны безымянные shared_ptr;
• какие опасности подстерегают при использовании shared_ptr в многопоточной среде;
• о чем важно помнить, создавая свою собственную освобождающую функцию для shared_ptr;
• какие существуют особенности использования шаблона enable_shared_from_this.

Описанные проблемы имеют место как для boost::shared_ptr, так и для std::shared_ptr. В конце статьи вы найдете приложение с полными текстами программ, написанных для демонстрации описываемых особенностей (на примере библиотеки boost).

Перекрестные ссылки

Данная проблема является наиболее известной и связана с тем, что указатель shared_ptr основан на подсчете ссылок. Для экземпляра объекта, которым владеет shared_ptr, создается счетчик. Этот счетчик является общим для всех shared_ptr, указывающих на данный объект. При конструировании нового объекта создается объект со счетчиком и в него помещается значение 1. При копировании счетчик увеличивается на 1. При вызове деструктора (или при замене указателя путем присваивания, или вызова reset), счетчик уменьшается на 1.

Рассмотрим пример:struct Widget { shared_ptr otherWidget;}; void foo() { shared_ptr a(new Widget); shared_ptr b(new Widget); a->otherWidget = b; // В этой точке у второго объекта счетчик ссылок = 2 b->otherWidget = a; // В этой точке у обоих объектов счетчик ссылок = 2} Что произойдет при выходе объектов a и b из области определения? В деструкторе уменьшатся ссылки на объекты. У каждого объекта будет счетчик = 1 (ведь a все еще указывает на b, а b — на a).

Объекты “держат” друг друга и у нашего приложения нет возможности получить к ним доступ — эти объекты “потеряны”. Для решения этой проблемы существует weak_ptr. Одним из типичных случаев создания перекрестных ссылок является случай, когда один объект владеет коллекцией других объектов struct RootWidget { list widgets;}; struct Widget { shared_ptr parent;}; При таком устройстве каждый Widget будет препятствовать удалению RootWidget и наоборот. В таком случае нужно ответить на вопрос: “Кто кем владеет?”.

Очевидно, что именно RootWidget в данном случае владеет объектами Widget, а не наоборот. Поэтому модифицировать пример нужно так: struct Widget { weak_ptr parent;}; Слабые ссылки не препятствуют удалению объекта. Они могут быть преобразованы в сильные двумя способами: 1) Конструктор shared_ptrweak_ptr w = …;// В случае, если объект уже удален, в конструкторе shared_ptr будет сгенерировано исключениеshared_ptr p( w ); 2) Метод lockweak_ptr w = …;// В случае, если объект уже удален, то p будет пустым указателемif( shared_ptr p = w.

lock() ) {// Объект не был удален – с ним можно работать}
Вывод: В случае возникновения в коде кольцевых ссылок, используйте weak_ptr для решения проблем.

Безымянные указатели

Проблема безымянных указателей относится к вопросу о “точках следования” (sequence points)// shared_ptr, который передается в функцию foo — безымянныйfoo( shared_ptr(new Widget), bar() ); // shared_ptr, который передается в функцию foo имеет имя pshared_ptr p(new Widget);foo( p, bar() ); Из этих двух вариантов документация рекомендует всегда использовать второй — давать указателям имена. Рассмотрим пример, когда функция bar определена вот так:int bar() { throw std::runtime_error(“Exception from bar()”);} Дело в том, что в первом случае порядок конструирования не определен.

Все зависит от конкретного компилятора и флагов компиляции. Например, это может произойти так:

1. new Widget
2. вызов функции bar
3. конструирование shared_ptr
4. вызов функции foo

Наверняка можно быть уверенным лишь в том, что вызов foo будет последним действием, а shared_ptr будет сконструирован после создания объекта (new Widget). Однако никаких гарантий того, что он будет сконструирован сразу после создания объекта, нет.

Если во время второго шага будет сгенерировано исключение (а оно в нашем примере сгенерировано будет), то Widget будет считаться сконструированным, но shared_ptr еще не будет им владеть. В итоге ссылка на этот объект будет потеряна. Я проверил данный пример на gcc 4.7.2. Порядок вызова был таким, что shared_ptr+new вне зависимости от опций компиляции не разделялись вызовом bar. Но полагаться именно на такое поведение не стоит – это не гарантировано. Буду признателен, если мне подскажут компилятор, его версию и опции компиляции, для которых подобный код приведет к ошибке.

Еще одна возможность для обхода проблемы анонимных shared_ptr — это использование функций make_shared или allocate_shared. Для нашего примера это будет выглядеть так: foo( make_shared(), bar() ); Данный пример выглядит даже более лаконично, чем исходный, а так же обладает рядом преимуществ в плане выделения памяти (вопросы эффективности оставим за пределами статьи). Допустим вызов make_shared с любым количество аргументов. Например следующий код вернет shared_ptr на строку, созданную через конструктор с одним параметром.

make_shared(«shared string»);
Вывод: Давайте shared_ptr имена, даже если код будет от этого менее лаконичным, либо воспользуйтесь для создания объектов функциями make_shared и allocate_shared.

Проблема использования в разных потоках

Подсчет ссылок в shared_ptr построен с использованием атомарного счетчика. Мы без опаски используем указатели на один и тот же объект из разных потоков. Во всяком случае, мы не привыкли беспокоиться о подсчете ссылок (потокобезопасность самого объекта – другая проблема). Допустим, у нас есть глобальный shared_ptr:shared_ptr globalSharedPtr(new Widget); void read() { shared_ptr x = globalSharedPtr; // Сделать что-нибудь с Widget} Запустите вызов read из разных потоков и вы увидите, что никаких проблем в коде не возникает (до тех пор, пока вы выполняете над Widget потокобезопасные для этого класса операции).

Допустим, есть еще одна функция:void write() { globalSharedPtr.reset( new Widget );} Устройство shared_ptr достаточно сложно, поэтому я приведу код, который схематически поможет показать проблему. Разумеется, настоящий код выглядит иначе.shared_ptr::shared_ptr(const shared_ptr& x) {A1: pointer = x.pointer;A2: counter = x.

counter;A3: atomic_increment( *counter );} shared_ptr::reset(T* newObject) {B1: if( atomic_decrement( *counter ) == 0 ) {B2: delete pointer;B3: delete counter;B4: }B5: pointer = newObject;B6: counter = new Counter;} Допустим, первый поток начал копировать globalSharedPtr (read), а второй поток вызывает reset для этого же экземпляра указателя (write). В итоге может получиться следующее:

1. Поток1 только что выполнил строку A2, но еще не перешел к строке A3 (атомарный инкремент).
2. Поток2 в это время уменьшил счетчик на строке B1, увидел, что после уменьшения счетчик стал равен нулю и выполнил строки B2 и B3.

3. Поток1 доходит до строки A3 и пытается атомарно увеличить счетчик, которого уже нет.

А может быть и так, что поток1 на строке A2 успеет увеличить счетчик до того, как поток2 вызовет удаление объектов, но после того как поток2 произвел уменьшение счетчика. Тогда мы получим новый shared_ptr, указывающий на удаленный счетчик и объект. Можно написать подобный код:shared_ptr globalSharedPtr(new Widget);mutex_t globalSharedPtrMutex; void resetGlobal(Widget* x) { write_lock_t l(globalSharedPtrMutex); globalSharedPtr.

reset( x );} shared_ptr getGlobal() { read_lock_t l(globalSharedPtrMutex); return globalSharedPtr;} void read() { shared_ptr x = getGlobal(); // Вот с этим x теперь можно работать} void write() { resetGlobal( new Widget );} Теперь, используя такие функции, можно безопасно работать с этим shared_ptr.

Вывод: если какой-то экземпляр shared_ptr доступен разным потокам и может быть модифицирован, то необходимо позаботиться о синхронизации доступа к этому экземпляру shared_ptr.

Особенности времени разрушения освобождающего функтора для shared_ptr

Данная проблема может иметь место только в том случае, если вы используете собственный освобождающий функтор в сочетании со слабыми указателями (weak_ptr). Например, вы можете создать shared_ptr на основе другого shared_ptr, добавив новое действие перед удалением (по сути шаблон “Декоратор”). Так вы могли бы получить указатель для работы с базой данных, изъяв его из пула соединений, а по окончании работы клиента с указателем — вернуть его обратно в пул.

typedef shared_ptr ptr_t; class ConnectionReleaser { list& whereToReturn; ptr_t connectionToRelease;public: ConnectionReleaser(list& lst, const ptr_t& x):whereToReturn(lst), connectionToRelease(x) {} void operator()(Connection*) { whereToReturn.push_back( connectionToRelease );// Обратите внимание на следующую строчку connectionToRelease.reset(); }}; ptr_t getConnection() { ptr_t c( connectionList.back() ); connectionList.pop_back(); ptr_t r( c.

get(), ConnectionReleaser( connectionList, c ) ); return r; }
Проблема заключается в том, что объект, переданный в качестве освобождающего функтора для shared_ptr, будет разрушен только тогда, когда все ссылки на объект будут уничтожены — как сильные(shared_ptr), так и слабые(weak_ptr). Таким образом, если ConnectionReleaser не позаботится о том, чтобы “отпустить” переданный ему указатель (connectionToRelease), он будет держать сильную ссылку, пока существует хотя бы один weak_ptr от shared_ptr, созданного функцией getConnection. Это может привести к достаточно неприятному и неожиданному поведению вашего приложения.

get(), boost::bind(&releaseConnection, boost::ref(connectionList), c) ); return r;} Помните, что bind копирует переданные ему аргументы (кроме случая с использованием boost::ref), и если среди них будет shared_ptr, то его тоже следует очистить, дабы избежать уже описанной проблемы.

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

Особенности работы с шаблоном enable_shared_from_this

Иногда требуется получить shared_ptr из методов самого объекта. Попытка создания нового shared_ptr от this приведет к неопределенному поведению (скорее всего к аварийному завершению программы), в отличие от intrusive_ptr, для которого это является обычной практикой. Для решения этой проблемы был придуман шаблонный класс-примесь enable_shared_from_this. Шаблон enable_shared_from_this устроен следующим образом: внутри класса содержится weak_ptr, в который при конструировании shared_ptr помещается ссылка на этот самый shared_ptr. При вызове метода shared_from_this объекта, weak_ptr преобразуется в shared_ptr через конструктор. Схематически шаблон выглядит так:template class enable_shared_from_this { weak_ptr weak_this_;public: shared_ptr shared_from_this() { // Преобразование слабой ссылки в сильную через конструктор shared_ptr shared_ptr p( weak_this_ ); return p; }}; class Widget: public enable_shared_from_this {}; Конструктор shared_ptr для этого случая схематически выглядит так:shared_ptr::shared_ptr(T* object) { pointer = object; counter = new Counter; object->weak_this_ = *this;} Важно понимать, что при конструировании объекта weak_this_ еще ни на что не указывает. Правильная ссылка в нем появится только после того, как сконструированный объект будет передан в конструктор shared_ptr. Любая попытка вызова shared_from_this из конструктора приведет к bad_weak_ptr исключению.struct BadWidget: public enable_shared_from_this { BadWidget() { // При вызове shared_from_this() будет сгенерировано bad_weak_ptr cout

Источник: https://habr.com/post/191018/