if you hate writing and trying to test multithreaded code raise your hand
-
I'm implementing thread safety on a large class after the fact. i hate this. but it has to be done. also Microsoft, what the hell. you didn't put versioning on your dictionary enumerators** ** means when the dictionary is changed the enumerator won't throw like it's supposed to.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I'm implementing thread safety on a large class after the fact. i hate this. but it has to be done. also Microsoft, what the hell. you didn't put versioning on your dictionary enumerators** ** means when the dictionary is changed the enumerator won't throw like it's supposed to.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
I could write an entire article p() and v() Considered Harmful. Just as the use of
gotoshould usually be restricted to the compiler, thread safety should usually be restricted to a few places by using cooperative scheduling (running work to completion). Willy-nilly preemptive scheduling is an abomination that causes artificial complexity, polluting the code with stuff that has nothing to do with the specifications. -
I could write an entire article p() and v() Considered Harmful. Just as the use of
gotoshould usually be restricted to the compiler, thread safety should usually be restricted to a few places by using cooperative scheduling (running work to completion). Willy-nilly preemptive scheduling is an abomination that causes artificial complexity, polluting the code with stuff that has nothing to do with the specifications.so you are a fan of cooperative threading? I can see the appeal, but it does very little when it comes to utilizing more than one CPU/core. At that point, you're going to have concurrency issues save some higher level task functionality included as part of the CPU architecture. Besides, i think cooperative multithreading is better handled using coroutines. That way the code design in clearer. In c#, coroutines are built using the yield statement.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
so you are a fan of cooperative threading? I can see the appeal, but it does very little when it comes to utilizing more than one CPU/core. At that point, you're going to have concurrency issues save some higher level task functionality included as part of the CPU architecture. Besides, i think cooperative multithreading is better handled using coroutines. That way the code design in clearer. In c#, coroutines are built using the yield statement.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Yes, I'm a big fan of cooperative threading. I haven't worked in C#, but I'd guess that
yield()does the same thing as what I callPause()in my code. Symmetric multiprocessing (SMP) is another abomination because it reintroduces the need for all this thread safety nonsense. It is lamentable that Intel ran contests on how to adapt software to these platforms. SMP is a case of the hardware team having fun at the expense of the software team, which we all know is backwards from how things should be! I also look at it this way, that there are only three good numbers: 0, 1, and infinity. So if I need more than one core, will 2, 4, or 8 always be enough? The general solution is to design software that runs in a distributed (networked) manner. This adds artificial complexity of its own, but it's the truly scalable solution and is unavoidable if you need an arbitrary amount of horsepower. The resulting software can also run on an SMP platform by dividing the shared memory so that each core has its own sandbox, with shared memory perhaps being used only for efficient interprocessor messaging. -
Yes, I'm a big fan of cooperative threading. I haven't worked in C#, but I'd guess that
yield()does the same thing as what I callPause()in my code. Symmetric multiprocessing (SMP) is another abomination because it reintroduces the need for all this thread safety nonsense. It is lamentable that Intel ran contests on how to adapt software to these platforms. SMP is a case of the hardware team having fun at the expense of the software team, which we all know is backwards from how things should be! I also look at it this way, that there are only three good numbers: 0, 1, and infinity. So if I need more than one core, will 2, 4, or 8 always be enough? The general solution is to design software that runs in a distributed (networked) manner. This adds artificial complexity of its own, but it's the truly scalable solution and is unavoidable if you need an arbitrary amount of horsepower. The resulting software can also run on an SMP platform by dividing the shared memory so that each core has its own sandbox, with shared memory perhaps being used only for efficient interprocessor messaging.Greg Utas wrote:
Yes, I'm a big fan of cooperative threading. I haven't worked in C#, but I'd guess that
yield()does the same thing as what I callPause()in my code.Probably "inside out" of what you're thinking. Assuming you call Pause() while inside a loop or something to yield time. yield however, is entirely different. It builds state machines for you to break apart the routine. Hence
IEnumerable Test() {
yield return "dog";
yield return "cat";
yield return "mouse";
}
...
foreach(var item in Test())
Console.WriteLine(item);yields dog cat mouse each time it encounters a yield return it returns from the function. The next time the function is called essentially it will start after that yield return statement at the next line. This voodoo is accomplished using a state machine the compiler builds for you. So each time the routine is called, it knows what state it's in and can execute the next instruction. So in your cooperative multithreading code. you'd just loop over whatever you needed to loop over, and time is returned to your function because the yield return dropped you out of the function in the "middle of the call" it's a lot easier to use than to explain, but it helps if you have familiarity with the concept of a coroutine first.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
Greg Utas wrote:
Yes, I'm a big fan of cooperative threading. I haven't worked in C#, but I'd guess that
yield()does the same thing as what I callPause()in my code.Probably "inside out" of what you're thinking. Assuming you call Pause() while inside a loop or something to yield time. yield however, is entirely different. It builds state machines for you to break apart the routine. Hence
IEnumerable Test() {
yield return "dog";
yield return "cat";
yield return "mouse";
}
...
foreach(var item in Test())
Console.WriteLine(item);yields dog cat mouse each time it encounters a yield return it returns from the function. The next time the function is called essentially it will start after that yield return statement at the next line. This voodoo is accomplished using a state machine the compiler builds for you. So each time the routine is called, it knows what state it's in and can execute the next instruction. So in your cooperative multithreading code. you'd just loop over whatever you needed to loop over, and time is returned to your function because the yield return dropped you out of the function in the "middle of the call" it's a lot easier to use than to explain, but it helps if you have familiarity with the concept of a coroutine first.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Interesting and not what I expected. Many folks couldn't be bothered to write a state machine, so we get blocking RPCs. And why do we get an hourglass or little spinning wheel on the screen? It's because some wanker couldn't be bothered to write a state machine! So I'm curious as to what kind of state machine this generates. It picks up where it left off, but a serious state machine handles any input that could arrive. I'm guessing that this blocks, which is OK sometimes (guaranteed low latency) but not others (waiting for a reply from another processor). It's the latter case that can put a little spinning wheel on the screen for an unbecoming length of time, which is loathsome.
-
Interesting and not what I expected. Many folks couldn't be bothered to write a state machine, so we get blocking RPCs. And why do we get an hourglass or little spinning wheel on the screen? It's because some wanker couldn't be bothered to write a state machine! So I'm curious as to what kind of state machine this generates. It picks up where it left off, but a serious state machine handles any input that could arrive. I'm guessing that this blocks, which is OK sometimes (guaranteed low latency) but not others (waiting for a reply from another processor). It's the latter case that can put a little spinning wheel on the screen for an unbecoming length of time, which is loathsome.
It does block but there's another mechanism that does what you're talking about (not blocking) It's called awaitable methods and basically they let you return pending a callback . for I/O bound operations, this is particularly desirable, but it's also helpful for CPU bound threads. The compiler builds a state machine so you can do like async bool StartJob() { var result = await DoLongRunningThing(); // method "exits" here, //pending a callback at which point it picks up here } sorry it's a bit contrived, but it's really easy once you get the hang of it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
It does block but there's another mechanism that does what you're talking about (not blocking) It's called awaitable methods and basically they let you return pending a callback . for I/O bound operations, this is particularly desirable, but it's also helpful for CPU bound threads. The compiler builds a state machine so you can do like async bool StartJob() { var result = await DoLongRunningThing(); // method "exits" here, //pending a callback at which point it picks up here } sorry it's a bit contrived, but it's really easy once you get the hang of it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
And I thought that C++ was a kitchen-sink language! That said, good on them that they allow other inputs. Not that I care for RPCs. But if this is in the thread's entry function, it's not much different than accepting any message that could arrive, so it looks like the kind of thing I'd aim for.
-
And I thought that C++ was a kitchen-sink language! That said, good on them that they allow other inputs. Not that I care for RPCs. But if this is in the thread's entry function, it's not much different than accepting any message that could arrive, so it looks like the kind of thing I'd aim for.
the var declaration is actually typed. The compiler picks up the type implicitly from the return value of the function it was initialized using; if I do: var i = 0; i will be an int. so i can't later do i = "foo"; // compile error it's helpful due to lack of typedefs for example.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I'm implementing thread safety on a large class after the fact. i hate this. but it has to be done. also Microsoft, what the hell. you didn't put versioning on your dictionary enumerators** ** means when the dictionary is changed the enumerator won't throw like it's supposed to.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I'm implementing thread safety on a large class after the fact. i hate this. but it has to be done. also Microsoft, what the hell. you didn't put versioning on your dictionary enumerators** ** means when the dictionary is changed the enumerator won't throw like it's supposed to.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Ouch, that is going to be a mess. It isnt that threads are difficult, it is that they are a fundamental part of the architecture, and need to go in first, not at the end, as a bodge. Probably better to redesign the whole thing.
-
Ouch, that is going to be a mess. It isnt that threads are difficult, it is that they are a fundamental part of the architecture, and need to go in first, not at the end, as a bodge. Probably better to redesign the whole thing.
it was fine. all i did is lock down all the non-private methods with a r/w slim lock. it can barely be called multithreaded coding
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I'm implementing thread safety on a large class after the fact. i hate this. but it has to be done. also Microsoft, what the hell. you didn't put versioning on your dictionary enumerators** ** means when the dictionary is changed the enumerator won't throw like it's supposed to.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
honey the codewitch wrote:
when the dictionary is changed the enumerator won't throw like it's supposed to
Are you sure about that?
var d = new Dictionary<int, int>
{
[1] = 1,
[42] = 24,
};foreach (var pair in d)
{
Console.WriteLine($"{pair.Key} = {pair.Value}");
d[42] *= 2;
}Output:
1 = 1
InvalidOperationException: Collection was modified; enumeration operation may not execute.Dictionary enumerator versioning | C# Online Compiler | .NET Fiddle[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
honey the codewitch wrote:
when the dictionary is changed the enumerator won't throw like it's supposed to
Are you sure about that?
var d = new Dictionary<int, int>
{
[1] = 1,
[42] = 24,
};foreach (var pair in d)
{
Console.WriteLine($"{pair.Key} = {pair.Value}");
d[42] *= 2;
}Output:
1 = 1
InvalidOperationException: Collection was modified; enumeration operation may not execute.Dictionary enumerator versioning | C# Online Compiler | .NET Fiddle[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Yes, I'm sure about that. I'm not talking about the Dictionary class in the BCL I'm talking about the KwData suite they released on codeplex
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
