есть примерный код


в m_device передается семафор, который захватывается при старте и освобождается при остановке.
Можно ли вынести блокировку семафора в делегат. Например:


Или делегат будет работать в контексте другого потока ?

Это сообщение отредактировал(а) xbarmaglot - 14.2.2013, 16:02

Да, метод MyTimer.run() будет выполнен в потоке таймера.

а какие еще есть варианты решения. Просто я не могу гарантировать вызов stop после старт, что приведет к блокировке семафора.

Для твоих целей лучше подойдет Condition.

LSD, почему ? чем он лучше ?

Идея в следующем: есть несколько устройств, которые пишут данные в файлы в одну папку.
Есть поток, который собирает эти файлы, архивирует и отсылает.
Так вот пока хоть одно устройство пишет, поток ничего не должен делать. Иначе передаст битые файлы.

Семафор говорит о том, что задействован хотя бы один писатель.
Но проблема в том, что последовательность start/stop не может ныть гарантирована.
Количество start может не соответствовать количеству stop. Либо stop может вообще не быть.
Но если старт был, то транзакцию нужно завершить - иначе блокировка семафора.

Вот и возникла идея вынести finally наружу.

Тогда у тебя классический ReadWriteLock, потоки которые пишут файлы захватывают read lock. Поток который архивирует write lock.
Read lock можно захватить много, write lock только один и пока он захвачен, ни один read lock захватить нельзя.

так проблема в том, что писатель может захватить, но можен не освободить.
А семафор это или ReadWriteLock - пофигу

Добавлено через 1 минуту и 17 секунд
А возникает это потому, что start и stop вызываются в разных потоках.
Был бы один поток - try/finnaly решил бы проблему

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

потому, что start и stop запускаются по разным событиям. Это системные события их запуск от меня не зависит

Тогда опишите проблему детальнее.
Когда и что надо архивировать (или копировать) и как это привязано к загадачным старт и стоп.

а что не понятно в моем описании ?

Добавлено через 14 секунд
спрашивай...

ну если берем это описание то дето так:


 Ну и как бы готово.
Или есть какие-то проблемы, которые я не понимаю?


Это сообщение отредактировал(а) korian - 14.2.2013, 19:19

Есть - писатель делает так



А они могут вызываться в любой последовательности и из разных потоках.
Может блокировать папку ?

Ну как бы, для начала хотелось бы понять, почему так получилось.

ну получается так

1. start, start - stop
2. start - stop
3. start - stop, stop
...

Главное, если был старт, то транцакция началась и должна закончиться.
Почему так - не от меня зависит, а от системы

Добавлено через 1 минуту и 59 секунд
главный вопрос - как как в данном случае синхронизироваться, если старт и стоп в разных потоках вызываются.
Может отдельный поток заводить ?

а почему семафор лочится на старте, а не на дейтсвии - т.е. перед записью в файл
и разлочивается при стопе, а не после того как запись совершилась?
короче тут как не крути но надо свести задачу к тому, что я написал
или переформулировать задачу в другую, а для этого надо детали.
Что такое девайс, что делает device.start, device.stop, почему они что-то лочат или разлочивают. Почему стоп и старт дергаются разными потоками. Это вообще разные процессы или один?

Это сообщение отредактировал(а) korian - 15.2.2013, 00:02

Сколько потоков пишут файл?

хороший вопрос


Это один процесс. device.start, device.stop просто пишут данные.
стоп и старт - дергаются при поступлении событий из системы - BroadcastReceiver.
Поэтому и разделена синхронизация. А вот как сделать атомарно - не знаю.

Да вроде деталей достаточно 

Добавлено через 33 секунды

могут писать до 6 потоком - сейчас. А вообще не обраниченно

Добавлено через 1 минуту и 22 секунды
Вернее все потоки пишут разные файлы

Одновременно? В смысле используя один и тот же FileOutputStrean или по очереди открывая свой FileOutputStrean?


А теперь хотелось бы увидеть полный flow:
- Поступает внешнее событие device.start
- <описание того что должно произойти после start>
- Поступает внешнее событие device.stop
- <описание того что должно произойти после stop>

Это все разные  FileOutputStrem. То есть каждый поток - свой файл.



создается файл и начинается запись.


заканчивается запись. закрывается файл.

Не думал, что это вызовет столько вопросов...

А откуда 6 потоков взялось? В каком порядке они работают?



А где архивация?




Извини конечно, но ты совершенно не умеешь объяснять, что требуется сделать.

6 потоков - 6 устройств. Работают независимо друг от друга.



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



Да вроде проще некуда  Есть писатели, а есть архиватор. Все это хозяйство должно быть синхроницированно.
Не знаю как проще объяснить...

Как они между собой арбитраж доступа к файлу реализуют?




Это уже понятно. Непонятно по какому условию активируется архивация. Что будет если в процессе архивации придет команда device.start? Почему надо блокировать архивацию по команде device.start а не тогда, когда начнется реальная запись в файл?

это разные файлы в одной директории



просто просыпается поток и пытается на семафоре определить, что никто не пишет



писатель будет ждять завершения архивации. эта операция довольно быстрая - 1-3 секунды. 
После того, как архивация закончится семафор освобождается и писатель начинает писать.



так при start и начинается реальная запись

Блин! Я тебя спросил:

ты ответил

а потом выясняется что:




В общем нет никаких проблем использовать RW lock, ему тут самое место.

я об этом сразу говорил, что это разные файлы



что RWLock, что семафор - разницы нет.
Моя проблема в том, что может быть несколько start или stop подряд.
Или RW как раз и игнорируют эту проблему...

xbarmaglot, дык это разрешено. Несколько start'ов - захват нескольких read-локов, stop - их освобождение. Архивация же захватывает write lock.