Newest at the top
2025-06-23 14:05:03 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 276 seconds) |
2025-06-23 14:04:19 +0200 | soverysour | (~soverysou@user/soverysour) (Ping timeout: 276 seconds) |
2025-06-23 14:03:41 +0200 | ystael | (~ystael@user/ystael) ystael |
2025-06-23 14:01:59 +0200 | talisc | (~talisc@user/talisc) (Excess Flood) |
2025-06-23 14:00:23 +0200 | trickard_ | trickard |
2025-06-23 13:52:54 +0200 | soverysour | (~soverysou@user/soverysour) soverysour |
2025-06-23 13:52:54 +0200 | soverysour | (~soverysou@84.232.150.229) (Changing host) |
2025-06-23 13:52:53 +0200 | soverysour | (~soverysou@84.232.150.229) soverysour |
2025-06-23 13:44:39 +0200 | merijn | (~merijn@77.242.116.146) merijn |
2025-06-23 13:41:16 +0200 | soverysour | (~soverysou@user/soverysour) (Ping timeout: 265 seconds) |
2025-06-23 13:38:22 +0200 | fp1 | (~Thunderbi@2001:708:20:1406::10c5) fp |
2025-06-23 13:37:46 +0200 | trickard_ | (~trickard@cpe-61-98-47-163.wireline.com.au) |
2025-06-23 13:37:27 +0200 | trickard_ | (~trickard@cpe-61-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
2025-06-23 13:36:05 +0200 | acidjnk | (~acidjnk@p200300d6e70b661750c15e2a18f5d35c.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
2025-06-23 13:31:31 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: irc.renjuan.org (juan@acm.org)) |
2025-06-23 13:31:01 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
2025-06-23 13:29:32 +0200 | <[exa]> | (pls check out the lucene segmentation) |
2025-06-23 13:28:45 +0200 | prdak | (~Thunderbi@user/prdak) prdak |
2025-06-23 13:28:30 +0200 | <[exa]> | yes but that's a completely impossible behavior here, writes must not cause locks |
2025-06-23 13:28:30 +0200 | xff0x | (~xff0x@2405:6580:b080:900:55ec:c9f:e8b1:7eb5) |
2025-06-23 13:28:25 +0200 | <Maxdamantus> | [exa]: so the one you describe as easier just seems like a variation of a read-write lock that assumes that while the lock is held in write mode, noone else will try to acquire it again in write mode. |
2025-06-23 13:27:07 +0200 | <Maxdamantus> | [exa]: that sounds like the distinction I was describing. Normally a read-write lock will "allow concurrent writes" by ensuring that only one actor can hold the lock when they access it in write mode. |
2025-06-23 13:25:24 +0200 | trickard_ | (~trickard@cpe-61-98-47-163.wireline.com.au) |
2025-06-23 13:25:09 +0200 | trickard_ | (~trickard@cpe-61-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
2025-06-23 13:24:15 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
2025-06-23 13:23:41 +0200 | soverysour | (~soverysou@user/soverysour) soverysour |
2025-06-23 13:23:41 +0200 | soverysour | (~soverysou@84.232.150.229) (Changing host) |
2025-06-23 13:23:41 +0200 | soverysour | (~soverysou@84.232.150.229) |
2025-06-23 13:22:48 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 276 seconds) |
2025-06-23 13:21:40 +0200 | <[exa]> | (btw no mutexes, mutexes don't do availability well) |
2025-06-23 13:20:13 +0200 | <[exa]> | (read: there's many lockpoints and some extra buffers for handling the possible write conflicts) |
2025-06-23 13:20:12 +0200 | <[exa]> | no, 2 different designs of a data structure, one that allows concurrent writes and reads but the writes have to be managed by a central point to avoid write conflicts (in turn the locking scheme there is a bit easier, something like the RCUs in kernels), and one that allows concurrent writes without any other synchronization going on, because the structure is more complex and thus "ready" for it |
2025-06-23 13:17:19 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
2025-06-23 13:16:39 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 245 seconds) |
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) |