Newest at the top
| 2025-06-23 13:12:20 +0200 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 244 seconds) |
| 2025-06-23 13:07:51 +0200 | <Maxdamantus> | and where the other is just a plain read-write lock, where the write lock part is essentially a mutex? |
| 2025-06-23 13:07:39 +0200 | trickard_ | (~trickard@cpe-61-98-47-163.wireline.com.au) |
| 2025-06-23 13:07:27 +0200 | <Maxdamantus> | "both structures"? are you talking about two types of read-write lock, where one is the "dangerous" variant that makes the assumption I described above? |
| 2025-06-23 13:07:24 +0200 | trickard_ | (~trickard@cpe-61-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-06-23 13:06:09 +0200 | <[exa]> | but that's common to both structures |
| 2025-06-23 13:06:07 +0200 | <Maxdamantus> | eg, DangerousReadWriteLock or something. |
| 2025-06-23 13:05:37 +0200 | <Maxdamantus> | I'd probably just call it a read-write lock tbh. If you want to optimise it such that it assumes noone else will try to acquire the write lock while the write lock is already held, you could just come up with a variation of the name. |
| 2025-06-23 13:04:50 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-06-23 13:04:13 +0200 | <[exa]> | there's one kinda simple as lucene does which must have all writes managed by one program, and there's another way which can have multiple independent writers but the locking gets quite complex |
| 2025-06-23 13:03:35 +0200 | <[exa]> | so I'm finding the proper labels to distinguish them :D |
| 2025-06-23 13:03:26 +0200 | <[exa]> | nah there's 2 ways to implement the data structure |
| 2025-06-23 13:03:19 +0200 | <Maxdamantus> | if it's the latter, then that's exactly what a read-write lock is. |
| 2025-06-23 13:03:12 +0200 | <[exa]> | so there's a whole lock hierarchy, the actual top is kinda compare-and-swapped very rarely by the writers |
| 2025-06-23 13:03:11 +0200 | <Maxdamantus> | actually, I guess there could be a wording issue here. when you say single writer, are you saying your code is already guaranteed to only write from one thread, or are you saying that the datastructure must enforce that? |
| 2025-06-23 13:02:40 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 244 seconds) |
| 2025-06-23 13:02:19 +0200 | <[exa]> | it's for a store of inverted indices, kinda like lucene segments |
| 2025-06-23 13:01:55 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 276 seconds) |
| 2025-06-23 13:01:54 +0200 | <Maxdamantus> | (though again, a read-write lock is theoretically more general, since it allows multiple writers) |
| 2025-06-23 13:01:48 +0200 | jespada | (~jespada@r179-25-124-186.dialup.adsl.anteldata.net.uy) jespada |
| 2025-06-23 13:01:24 +0200 | <Maxdamantus> | Well, if you don't want a queue, I guess what you want is just a read-write lock. |
| 2025-06-23 13:00:56 +0200 | <[exa]> | doesn't fit totally but so far closest :D |
| 2025-06-23 13:00:47 +0200 | <[exa]> | anyway yeah I guess that's exactly what I wasn't able to recall |
| 2025-06-23 13:00:06 +0200 | <[exa]> | *communication |
| 2025-06-23 13:00:02 +0200 | <[exa]> | but that's more like for communion channel kind of things, right? |
| 2025-06-23 12:59:55 +0200 | <Maxdamantus> | multi-producer single-consumer, multi-producer multi-consumer |
| 2025-06-23 12:59:36 +0200 | <[exa]> | oh producer and consumer |
| 2025-06-23 12:59:34 +0200 | <Maxdamantus> | producer, consumer |
| 2025-06-23 12:59:28 +0200 | <[exa]> | what does 'p' and 'c' stand for there? |
| 2025-06-23 12:59:07 +0200 | <Maxdamantus> | I guess "mpmc" covers the use case, but that's more general than what you're asking for. |
| 2025-06-23 12:58:38 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-06-23 12:58:12 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-06-23 12:57:42 +0200 | <Maxdamantus> | actually, maybe that doesn't exist. I kind of assumed it did, since there is "mpsc" in std. |
| 2025-06-23 12:56:28 +0200 | <Maxdamantus> | as opposed to "mpsc". |
| 2025-06-23 12:56:21 +0200 | <Maxdamantus> | [exa]: in Rust I think I've seen it called "mcsp", or maybe it was "spmc". |
| 2025-06-23 12:55:46 +0200 | prdak | (~Thunderbi@user/prdak) prdak |
| 2025-06-23 12:52:05 +0200 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2025-06-23 12:50:25 +0200 | <[exa]> | doubles nicely with "simple" and "complex" |
| 2025-06-23 12:50:10 +0200 | <[exa]> | whatevs, I'll mark them SW and CW like serialized writer and concurrent writer |
| 2025-06-23 12:48:57 +0200 | <[exa]> | (I've got 2 variants of a segmented data structure here, with the many-writer having a more complex locking scheme and way more overhead) |
| 2025-06-23 12:47:41 +0200 | <[exa]> | likely |
| 2025-06-23 12:47:34 +0200 | <__monty__> | Is this one of those elementary things that never got named successfully? |
| 2025-06-23 12:47:26 +0200 | tmciver | (~tim@syn-198-255-177-240.res.spectrum.com) tmciver |
| 2025-06-23 12:47:20 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-06-23 12:46:30 +0200 | tmciver | (~tim@syn-198-255-177-240.res.spectrum.com) (Ping timeout: 244 seconds) |
| 2025-06-23 12:45:48 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-06-23 12:45:36 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2025-06-23 12:45:16 +0200 | <[exa]> | is there some common coined name for data structures that allow concurrent access for many readers but only a single writer (ie. all writes have to be serialized)? |
| 2025-06-23 12:45:11 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer) |
| 2025-06-23 12:44:02 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |