- Tricky ... - 25 Updates
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 01 11:08PM -0700 On 10/1/2021 11:00 PM, Bonita Montero wrote: >> between the two possible paths? > Lock-free is when there's no kernel-locking involved. > And a slow-path involves kernel-locking. One cal use lock-free in user-space! A futex or eventcount can be used to help it out. You know, if it must wait on an empty condition, well, it can without spinning around. If the queue/stack is empty, we can wait! Or not. Up to the programmer. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 01 11:12PM -0700 On 10/1/2021 11:00 PM, Bonita Montero wrote: >> do when one needs to wait, on say, an empty condition? Humm... Why do >> you troll? > Lock-free is when there's no kernel-locking involved. A fast-path can be 100% pure lock/wait-free, so yes; indeed. A slow-path can involve kernel locking. Are you late to the game? > And a slow-path involves kernel-locking. Yes. So, a lock/wait-free fast-path in user-space can be realized, right? Think about it, then think about it again. So can a slow-path. The target usage paradigm is to use a lot more fast-paths, than slow ones... ;^) |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 02 08:38AM +0200 Am 02.10.2021 um 08:12 schrieb Chris M. Thomasson: >> Lock-free is when there's no kernel-locking involved. > A fast-path can be 100% pure lock/wait-free, so yes; indeed. > A slow-path can involve kernel locking. Are you late to the game? And if you have kernel-locking you don't have any lock-free algorithm. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 02 08:38AM +0200 Am 02.10.2021 um 08:08 schrieb Chris M. Thomasson: > to help it out. You know, if it must wait on an empty condition, well, > it can without spinning around. If the queue/stack is empty, we can > wait! Or not. Up to the programmer. If you have a slow path you don't have a lock-free algorithm. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 01 11:39PM -0700 On 10/1/2021 11:38 PM, Bonita Montero wrote: >> A fast-path can be 100% pure lock/wait-free, so yes; indeed. >> A slow-path can involve kernel locking. Are you late to the game? > And if you have kernel-locking you don't have any lock-free algorithm. WRONG! Think of the difference between a fast-path and a slow-path. The programmer can decide what to do. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 01 11:41PM -0700 On 10/1/2021 11:38 PM, Bonita Montero wrote: >> it can without spinning around. If the queue/stack is empty, we can >> wait! Or not. Up to the programmer. > If you have a slow path you don't have a lock-free algorithm. Why not? The slow-path can be avoided, from time to time. Ever heard about doing something else, instead of waiting in kernel land? I have some older code that can show this. Its the type of thinking were... Well, why should I wait when I can do something else. Actually, it works. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 01 11:44PM -0700 On 10/1/2021 11:41 PM, Chris M. Thomasson wrote: > about doing something else, instead of waiting in kernel land? I have > some older code that can show this. Its the type of thinking were... > Well, why should I wait when I can do something else. Actually, it works. Think of a slow-path as being when a lock is locked; shit need to wait. And a fast-path as being able to acquire it without waiting. Well, instead of waiting, do something else? It can be coded, so to speak using some interesting logic. ;^) I am trying to teach you. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 02 08:46AM +0200 Am 02.10.2021 um 08:39 schrieb Chris M. Thomasson: >> And if you have kernel-locking you don't have any lock-free algorithm. > WRONG! Think of the difference between a fast-path and a slow-path. The > programmer can decide what to do. No, not wrong. Lock-free is always without waiting in the kernel, i.e. no locking. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 02 08:47AM +0200 Am 02.10.2021 um 08:41 schrieb Chris M. Thomasson: >>> can wait! Or not. Up to the programmer. >> If you have a slow path you don't have a lock-free algorithm. > Why not? The slow-path can be avoided, from time to time. ... Lock-free is without locking all the time. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 01 11:50PM -0700 On 10/1/2021 11:46 PM, Bonita Montero wrote: >> The programmer can decide what to do. > No, not wrong. Lock-free is always without waiting in the kernel, > i.e. no locking. You seem to really love the fast-path. So do I!!!! 100% pure lock/wait-free depending on the algorihtm we are targeting. However, we can wait on slow paths. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 01 11:51PM -0700 On 10/1/2021 11:47 PM, Bonita Montero wrote: >>> If you have a slow path you don't have a lock-free algorithm. >> Why not? The slow-path can be avoided, from time to time. ... > Lock-free is without locking all the time. Think of fast path vs slow path. You have a lot to learn! |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 02 08:52AM +0200 Am 02.10.2021 um 08:50 schrieb Chris M. Thomasson: > You seem to really love the fast-path. So do I!!!! 100% pure > lock/wait-free depending on the algorihtm we are targeting. > However, we can wait on slow paths. Lock-free algorithms are _always_ non-blocking, so there is never any slow path. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 02 08:53AM +0200 Am 02.10.2021 um 08:51 schrieb Chris M. Thomasson: >>> Why not? The slow-path can be avoided, from time to time. ... >> Lock-free is without locking all the time. > Think of fast path vs slow path. You have a lot to learn! I know the difference. But lock-free algorithms are _always_ non-blocking and _never_ have a slow path. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 02 12:01AM -0700 On 10/1/2021 11:52 PM, Bonita Montero wrote: >> However, we can wait on slow paths. > Lock-free algorithms are _always_ non-blocking, > so there is never any slow path. Have you experienced something that required you to wait on certain conditions? Call the wait path a slow-path. Make the fast-paths as fast as possible. Humm... Are you green? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 02 12:04AM -0700 On 10/1/2021 11:53 PM, Bonita Montero wrote: >> Think of fast path vs slow path. You have a lot to learn! > I know the difference. But lock-free algorithms are > _always_ non-blocking and _never_ have a slow path. ARGH! You are a pain to talk to. There is a way to use this even in mutex logic. The slow path of a mutex is when its locked, and we have a choice to wait, or perhaps try to do something else... Think about it! |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 02 09:12AM +0200 Am 02.10.2021 um 09:01 schrieb Chris M. Thomasson: > Have you experienced something that required you to wait on certain > conditions? Call the wait path a slow-path. Make the fast-paths as > fast as possible. Humm... Are you green? There is no slow path with lock-free algorithms. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 02 09:13AM +0200 Am 02.10.2021 um 09:04 schrieb Chris M. Thomasson: > ARGH! You are a pain to talk to. There is a way to use this even in > mutex logic. The slow path of a mutex is when its locked, and we have a > choice to wait, or perhaps try to do something else... Think about it! A mutex isn't a lock-free structure because is _also_ has a slow path. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 02 12:20AM -0700 On 10/2/2021 12:13 AM, Bonita Montero wrote: >> about it! > A mutex isn't a lock-free structure because is _also_ has a > slow path. It can have a very nice fast-path... Have you ever created one? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 02 12:24AM -0700 On 10/2/2021 12:13 AM, Bonita Montero wrote: >> about it! > A mutex isn't a lock-free structure because is _also_ has a > slow path. Have you ever experimented with trying to do something else instead of waiting on a mutex? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 02 12:26AM -0700 On 10/2/2021 12:12 AM, Bonita Montero wrote: >> conditions? Call the wait path a slow-path. Make the fast-paths as >> fast as possible. Humm... Are you green? > There is no slow path with lock-free algorithms. What about a stack-empty condition? You seem to be stunted in your thinking, for some damn reason. Are you this way on purpose???? |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 02 09:30AM +0200 Am 02.10.2021 um 09:20 schrieb Chris M. Thomasson: >> A mutex isn't a lock-free structure because is _also_ has a >> slow path. > It can have a very nice fast-path... Have you ever created one? That's not what we're talking about. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 02 09:31AM +0200 Am 02.10.2021 um 09:24 schrieb Chris M. Thomasson: >> slow path. > Have you ever experimented with trying to do something else instead of > waiting on a mutex? That's not what we're talking about. Lock-free is when there is never any waiting in the kernel. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 02 12:31AM -0700 On 10/1/2021 6:08 AM, Branimir Maksimovic wrote: >>> Why? >> Because you don't have to wait in the kernel. > If you don't spin it is not lock :P True. Hitting the fast path is very nice indeed! > problem is that only way you don't synchronize > is when things are *independent* from each other :P Well, sometimes one can do other things instead of spinning/waiting, even in a mutex locked condition. Its an interesting simple logic loop. You have probably seen it before. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 02 12:32AM -0700 On 10/2/2021 12:30 AM, Bonita Montero wrote: >>> slow path. >> It can have a very nice fast-path... Have you ever created one? > That's not what we're talking about. I am talking about the nice fast-path being totally lock/wait-free. It can! Think about it some more. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 02 12:32AM -0700 On 10/2/2021 12:31 AM, Bonita Montero wrote: >> waiting on a mutex? > That's not what we're talking about. > Lock-free is when there is never any waiting in the kernel. Lock-free is when its lock-free. Ugh! |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment