Newest at the top
| 2025-06-23 14:16:22 +0200 | acidjnk | (~acidjnk@p200300d6e70b661750c15e2a18f5d35c.dip0.t-ipconnect.de) acidjnk |
| 2025-06-23 14:15:58 +0200 | califax | (~califax@user/califx) califx |
| 2025-06-23 14:15:35 +0200 | soverysour | (~soverysou@user/soverysour) (Ping timeout: 260 seconds) |
| 2025-06-23 14:14:16 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-06-23 14:10:50 +0200 | trickard_ | (~trickard@cpe-61-98-47-163.wireline.com.au) |
| 2025-06-23 14:10:37 +0200 | trickard | (~trickard@cpe-61-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-06-23 14:08:49 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
| 2025-06-23 14:07:59 +0200 | soverysour | (~soverysou@user/soverysour) soverysour |
| 2025-06-23 14:07:59 +0200 | soverysour | (~soverysou@84.232.150.229) (Changing host) |
| 2025-06-23 14:07:59 +0200 | soverysour | (~soverysou@84.232.150.229) |
| 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 |