Да, все теперь записывается в файл, но когда я убираю .new - он просто пишет все в один файл {} в рутовой директории скрипта. А мне нужно вывод для каждого файла писать в этот же файл ( перезаписывать )
Олег Цилюрик:
Прошу прощения, вот исходный текст задачи:
Напишите программу, которая создает нить. Используйте атрибуты по умолчанию. Родительская и вновь созданная нити должны распечатать десять строк текста. Модифицируйте программу так, чтобы вывод родительской и дочерней нитей был синхронизован: сначала родительская нить выводила первую строку, затем дочерняя, затем родительская вторую строку и т.д. Используйте мутексы.
Явные и неявные передачи управления между нитями (sleep(3C)/usleep(3C), sched_yield(3RT)) и холостые циклы разрешается использовать только на этапе инициализации.
Докажите, что данная задача не может быть решена с использованием двух мутексов без использования других средств синхронизации.
xmoonlight: ну вот например, мы можем пытаться реализовать множество разных вариантов. Например, создадим класс для каждого треда, в котором будет указатель на мьютекс текущего потока, и на мьютекс другого потока. Ну и в цикле проверять, если текущий свободен, то выводим пронумерованную строку на экран, потом освобождаем мьютексы. И какой-то мьютекс в самом начале захватить, до цикла. Но это не работает, может возникнуть race condition. Вот, очень схематично:
Я вижу, что это не возможно, но в голове мысль проскакивает, вдруг существует какая-нибудь другая реализация, при которой можно исхитриться так сделать. И не могу догнать, как строго доказать в принципе невозможность. Перебором всех вариантов? Но их же там огромное количество
Ну это-то из определения мьютекса исходит.
К сожалению, немного не догоняю, как это строго доказывает проблему. Не могли бы вы чуточку подробнее объяснить?
Почитал сорцы - теперь понял. У нас putenv к тому же еще и thread-safe. Ну на самом деле, работать изменение по environ будет, если новое значение переменной среды будет по размеру <= старого. А иначе вылетит SIGSEGV.
Ну и проблемы возникнут, если потом будем через putenv переменные добавлять.
jcmvbkbc: все верно говорите, я просто не правильно мысль сформулировал.
Конечно, когда превысим шаг предвыборки, там тогда в обоих случаях просто будет 2 L2 промаха, время должно быть одинаковым.
jcmvbkbc: понял свою ошибку - сравниваю теперь 2й и 3ий промах, время доступа к третьему становится в среднем больше, чем ко второму после 32 инт отступа. Можно ли это считать длиной предвыборки?
Я ожидал увидеть зашкаливание времени через N элементов смещения, что свидетельствовало бы о том, что этот элемент и последующие, не были загружены в L2 аппаратной предвыборкой данных.
