Comments 16
В системах с автоматически управлением памятью каждый объект имеет внутренний счетчик, который увеличивается каждый раз, когда кто-то получает ссылку на этот объект. Когда этот кто-то перестает использовать эту ссылку (например, присваивая Nil), внутренний счетчик объекта уменьшается.
Ну, если быть честным — то с введением ARC ситуация в этой сфере не поменялась вообще — внутренний счетчик был и ранее. ARC просто за программиста расставляет retain и release, не более того.
Ну и <зануда мод> есть еще всякие слабые ссылки, не увеличивающие счетчика, да и вообще </зануда мод>
уже сегодня можно опустить вызов alloc (наример, [NSSting stringWithFormat] работает так же, как [[NSString alloc] initWithFormat:]).
Это тоже очень и очень старая конструкция. Ранее она отличалась от alloc] init] встроенным авторелизом. Не стал бы говорить о том, что это в том или ином роде тенденция.
Относительно конструкции NSSting stringWithFormat:
На мой взгляд, это достаточно хороший индикатор того, куда может начать мигрировать iOS, а именно, в сторону полной автоматизации управления памятью. Как вы понимаете, эта конструкция появилась не из головы какого-то разработчика. Она была описана в архитектуре, прошло достаточно серьезные обсуждения, была одобрена и внедрена в язык. Если в ближайшие годы Apple не откажется от развития Objective C, полностью переорентировавшись на Swift, то мы увидим еще много интересных изменений.
Сегодня объекты нужно создавать явным образом. При этом уничтожаются они автоматически. Это идет вразрез с общей идеологией изменений языка.
Поглядим.
На мой взгляд, это достаточно хороший индикатор того, куда может начать мигрировать iOS, а именно, в сторону полной автоматизации управления памятью. Как вы понимаете, эта конструкция появилась не из головы какого-то разработчика. Она была описана в архитектуре, прошло достаточно серьезные обсуждения, была одобрена и внедрена в язык. Если в ближайшие годы Apple не откажется от развития Objective C, полностью переорентировавшись на Swift, то мы увидим еще много интересных изменений.
Сегодня объекты нужно создавать явным образом. При этом уничтожаются они автоматически. Это идет вразрез с общей идеологией изменений языка.
Поглядим.
Не могу согласиться, что это направление для миграции, так как такого рода синтаксис был с самого начала iOS и всегда был в параллели с alloc-init. Соответственно нет никаких предпосылок, что эта ситуация будет меняться в ту или иную сторону.
К слову — в свифте ситуация с управлением памятью практически такая же, просто не предоставлено явных инструментов для ручного управление (что не говорит, что мы не можем к ним обращаться).
К слову — в свифте ситуация с управлением памятью практически такая же, просто не предоставлено явных инструментов для ручного управление (что не говорит, что мы не можем к ним обращаться).
Я смотрю на то, что относительно недавно появился ARC. Это шаг в направлении автоматизации — теперь объекты освобождаются автоматически. И вот в iOS наблюдается странная ассиметрия: объекты надо создавать, но не надо освобождать. Это нелогично. Более того, автоматическая алокация объекта с точки зрения управления памятью — это просто, это намного проще, чем ARC. Мне очень сложно представить себе ситуацию, в которой попытка записи в неалоцированнай объект (и как следствие invalid page fault) не является багом.
Я не понял, а зачем вы сравниваете «коллекции» в user-space и kernel-space? Там же принципиально разные подходы к управлению ресурсами. Если уж на то пошло, то больше смысла будет в сравнении с IOKit.
Я не сравниваю коллекции в Objective C и в ядре: в ядре нет коллекций. Я просто привел список основных примитивов, доступных в обеих системах для организации данных. И именно для того, чтобы показать их разницу.
В основном мне интересен именно тот факт, что один и тот же концепт, причем практически неизменном виде, присутствует в таких перпендикулярных системах, как iOS достаточно высокого уровня, и низкоуроневое ядро Linux.
В основном мне интересен именно тот факт, что один и тот же концепт, причем практически неизменном виде, присутствует в таких перпендикулярных системах, как iOS достаточно высокого уровня, и низкоуроневое ядро Linux.
Про концепт — это вы про en.wikipedia.org/wiki/Reference_counting, который применяется еще в десятках других языков?
Да. Но дело в том, что в ни в стандартном C, ни в расширенном gcc нет встроенного механизма reference counting — просто потому, что это не языки, изначально построенные для ООП. Этим особенно и интересен refcounting в ядре — это относительно недавно внедренная конструкция. Когда я начинал работать с ядром, проблемы структур с общим доступом каждый решал как мог, и иногда мне попадались довольно странные идеи, явно списанные из каких-то других OS. Ядро вообще достаточно долго служило испытательным полигоном для людей из академии, которые притащили в него множество сложных и интересных для теоретиков идей и конструкций. В частности, постепенно ядро вбирало в себя все больше и больше различныех методик из ООП. Хорошо это или плохо — это уже филосовский вопрос.
Но RC несколько ортогонально ООП, вы не находите? Собственно, RC успешно применяется в С, в том коде, где нет понятий объектов или классов, а есть «общедоступные» структуры.
Не соглашусь. RC как раз является базой ООП. Часто его не видно, но он есть там, в недрах реализации объкта. В системах с автоматической сборкой мусора сложно представить что-то другое.
Необходимость в RC появляется в больших и недетерменированных системах, где сложно предсказать поведение — к сожалению, ООП часто приводит именно к этому. В небольшом функциональном проекте с десятком процессов просто нет необходимости в этой технике. И даже в ядре Linux RC появился только году так в 2006, а плотно использоваться стал еще позже. Да и сегодня при написании всякого рода драйверов RC используется относительно редко — драйвер создает несколько своих объектов, которые сам же при выходе и уничтожает. Гораздо чаще, на порядок чаще объекты синхронизации ядра это спинлоки и семафоры, в некоторых случаях даже просто атомарные счетчики, редко RCU.
Необходимость в RC появляется в больших и недетерменированных системах, где сложно предсказать поведение — к сожалению, ООП часто приводит именно к этому. В небольшом функциональном проекте с десятком процессов просто нет необходимости в этой технике. И даже в ядре Linux RC появился только году так в 2006, а плотно использоваться стал еще позже. Да и сегодня при написании всякого рода драйверов RC используется относительно редко — драйвер создает несколько своих объектов, которые сам же при выходе и уничтожает. Гораздо чаще, на порядок чаще объекты синхронизации ядра это спинлоки и семафоры, в некоторых случаях даже просто атомарные счетчики, редко RCU.
RC как раз является базой ООПRC — это модель управления временем жизни данных. ООП — это парадигма программирования. RC используется в коде без ООП, ООП используется в коде без RC. Я не очень понимаю ваш аргумент. Кроме того, RC — это не примитив синхронизации, к чему тут еще и семафоры появились? RC не избавляет вас от синхронизации доступа к данным.
Тут просто дергаются указатели
s = Nil; //В ячейку с адресом обьекта записали 0
NSString *s2 = s; //ячейку s2 записали адрес что и s
Я конечно понимаю что есть, АRC, но если человек не знаком с языком, нагляднее будет рассказать что есть явный вариант, и что у обьекта есть методы инкремента и декремента количества ссылок.
s = Nil; //В ячейку с адресом обьекта записали 0
NSString *s2 = s; //ячейку s2 записали адрес что и s
Я конечно понимаю что есть, АRC, но если человек не знаком с языком, нагляднее будет рассказать что есть явный вариант, и что у обьекта есть методы инкремента и декремента количества ссылок.
Ожидал здесь увидеть сравнение linux kernel с darwin/xnu. А так это «Что общего между зубами крокодила и пухом хомячка?»
Sign up to leave a comment.
Что общего между ядром Linux и iOS?