ээ, map[string]sync.Mutex

@lexszero Покажи как ты этим будешь пользоваться

@lexszero зачем стринг, если есть хеш?

@stiletto shit["key"].Lock()

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

@stiletto вообще, если я правильно угадал твой непитон, то часто когда xочетя нетривиальной xуйни с мутексами, то бывает полезно включить голову и отредизайнить на чянаx, создание: гм, не подумал. ну, врапперы, которые будут создавать мутекс если в мэпе для ключа ничего нету

@lexszero И удалять. Покажи этот враппер, лол.

Сделай защищенную мьютексом мапу. Lock() берет мьютекс, проверяет ключ, если его нет, добавляет и освобождает мьютекс. Если ключ уже существует, уходим в busywait (мьютекс освобождать не забудь; здесь, кстати, лучше подойдёт rw, чтобы те, кто в busywait, не мешали писателям). Unlock(), думаю, очевиден. Если не нравятся бузивейты, храни по ключу список тех, кто ждёт лока, и уведомляй первого в очереди, когда вызываешь Unlock() (не знаю, что за нотификаторы, но судя по названию, они тебе подойдут). Но это же костыли какие-то. Что за непитон, может, и правда передизайнить поудачнее?

@stiletto щас до эвм с нормальной клавой доберусь, 5мин

@minoru Я хочу ответ хотя бы псевдокодом, а не "ну это берешь и ебашишь" :/

Бля, ошибок напостил. Сейчас исправленную запощу

@stiletto не удаляй плиз

type MutexMap struct { lock sync.RWMutex lock2 sync.Mutex mutexes map[string]sync.Mutex } func (mm *MutexMap) Lock(name string) { mm.lock.Lock() lock, ok := mm.mutexes[name] if !ok { lock = sync.Mutex{} mm.mutexes[name] = lock } mm.lock2.Lock() mm.lock.Unlock() mm.lock.RLock() mm.lock2.Unlock() lock.Lock() mm.lock.RUnlock() } func (mm *MutexMap) Unlock(name string) { mm.lock.Lock() mm.lock2.Lock() lock, ok := mm.mutexes[name] if ok { lock.Unlock() } delete(mm.mutexes, name) mm.lock2.Unlock() mm.lock.Unlock() }

@stiletto тупая наивная реализация. нахуя удалять, я не понял. type MutexMap map[string]*sync.Mutex func (m *MutexMap) maybeCreate(key string) { if _, ok := m[key]; !ok { m[key] = new(sync.Mutex) } } func (m *MutexMap) Lock(key string) { m.maybeCreate(key) m[key].Lock() } func (m *MutexMap) Unlock(key string) { m.maybeCreate(key) m[key].Unlock() }

Если у тебя возникла необходимость в таком чудовище весьма вероятно что надо переосмыслить архитектуру чтобы потребность исчезла. Лочь весь мап и не пердолься с мьютексами в 2014, или всё повиснет дедлоком из-за тривиальной ошибки.

@lexszero Удалять затем, что в моем юзкейсе разных значений ключа может быть примерно 2²⁵⁶. Не одновременно

@stiletto ну, воткни удоление. тогда анлок будет примерно такой: if _, ok := m[key]; ok { m[key].Unlock() delete(m, key) } что за хуету с двумя мутексами ты нагородил я не распарсил. операции с мэпами в го и так атомарные.

@lexszero А теперь представь, что лок и анлок перемешались. Сначала в локе вызывается maybeCreate, он достает из мапа мьютекс. Затем анлок делает Unlock на этом мьютексе и удаляет его из массива. лок лочит мьютекс, который из массива уже удален.

@stiletto *ассоциативного массива

@stiletto окей, запихнуть в рвлок. но по-моему ты хуйню какую-то творишь.

@lexszero Ну ты запихни в рвлок и покажи код

@stiletto да, с рвлоком отсос. с обычным локом вроде нормик, но медленее. type MutexMap struct { m map[string]*sync.Mutex sync.Lock } func (m *MutexMap) Lock(key string) { m.m.Lock() defer m.Unlock() if _, ok := m.m[key]; !ok { m.m[key] = new(sync.Mutex) } m.m[key].Lock() } func (m *MutexMap) Unlock(key string) { m.Lock() defer m.Unlock() if mm, ok := m.m[key]; ok { mm.Unlock() delete(m.m, key) } }

@polecat этому мудаку Пайк дал чаны, а он мутексы жрет.

@lexszero Lock делает m.Lock(), затем вешается на m.m[key].Lock() и стоит ждёт. Unlock делает m.Lock() и виснет.

@lexszero У меня есть некое приложение, принимающее запросы по HTTP-API, а затем передающее их некоей другой штуковине. У запросов есть ключ. Я должен сделать, чтобы "другая штуковина" не получала нескольких запросов с одним и тем же ключом одновременно. Только когда закончится один запрос с таким ключом можно обрабатывать второй. Реализуй на каналах, ага.

@stiletto А, и да, запросы идут параллельно и имеют объем достаточный, чтобы их не хотелось буферизовать в памяти

@polecat Вешать чтение тела запроса до тех пор пока предыдущий запрос лок не отпустит

@polecat > лок(ключ) А я тут што по-твоему реализую