How does one respond to stupidity?
-
<FONT size=2>As the programer in charge of our MarketData information as well as our API I get to work with many developers. Today when working with one I received this email.
This person does not belive in threads and is requesting us to change our API to meet his thinking.
Our API is a threaded API and as such the callbacks do not come back on the main thread of the application. It seems this was noticed by the developer. Here is the comment I received.
</FONT>To be clear, what I mean by unstable is calling back on a thread other than the thread that made the function call requesting a callback. Being that the logon function is blocking and then there is a callback on another thread, that may not necessarily be unstable. But it could be.
Because what if that thread causes something to happen that uses data objects and then your logon function then unblocks and then the primary thread starts using those same data objects. That's what I mean by instability.
Callbacks should always be issued on the thread that made a function call that requested the callback. Not on another thread. Anyone who does that I consider a poor programmer including Microsoft. Because they engage in that kind of programming in some cases and this caused us a lot of trouble. This is just plain unstable especially if it is not documented. I don't care if you or other people don't agree. I am highly experienced with multithreaded programming. And that is why I don't allow our guys to engage in it unless it is absolutely necessary because I know the complexity of it. and the unpredictable problems it can cause. Even if it is only occasional.
All of our network I/O is 100% asynchronous and we get callbacks through window messages on the primary thread. We don't use timers and we don't use other threads. Sometimes we may dedicate a thread for network I/O, but still the callbacks occur within that same thread.
-
-
@fatdog said:
@Hellweek said:
How does one respond to stupidity?
backhand slap.
Brutal mockery. Call them ugly, poor, fat, whatever. Be sure to make liberal use of synonyms for "stupid" such as "retarded", "shit-for-brains" and "Mac user". Nothing you can say is taking it too far: the more exaggerated, the funnier it is for you and others and the more likely the person will jump off a bridge and remove themselves from the gene pool.
Good luck.
-
@Hellweek said:
<font size="2">
As the programer in charge of our MarketData information as well as our API I get to work with many developers. Today when working with one I received this email.
This person does not belive in threads and is requesting us to change our API to meet his thinking.
Our API is a threaded API and as such the callbacks do not come back on the main thread of the application. It seems this was noticed by the developer. Here is the comment I received.
</font>Because what if that thread causes something to happen that uses data objects and then your logon function then unblocks and then the primary thread starts using those same data objects. That's what I mean by instability.
just tell him to make his code thread-safe and there won't be any problems.
-
@Dude said:
Anyone who does that I consider a poor programmer including Microsoft. Because they engage in that kind of programming in some cases and this caused us a lot of trouble. This is just plain unstable especially if it is not documented. I don't care if you or other people don't agree. I am highly experienced with multithreaded programming. And that is why I don't allow our guys to engage in it unless it is absolutely necessary because I know the complexity of it. and the unpredictable problems it can cause.
Telltale rhetorical style of ignorance.
-
@Hellweek said:
But it could be.
@Hellweek said:
That's what I mean by instability.
@Hellweek said:
Not on another thread.
@Hellweek said:
I don't care if you or other people don't agree.
You know. To me it looks like. SpectateSwamp got a new job.
-
Actualy this is coming from a widly used charting software company. It blows my mind away that he is that so far behind the times.
-
Damn. I wrote a great reply to the OP but it ended up on a different thread.
-
@DOA said:
Damn. I wrote a great reply to the OP but it ended up on a different thread.
SLAAAPPP
fatdog backhand slaps DOA
See how this works?
-
@fatdog said:
@DOA said:
Hey, it's not my fault. A year and a half of reading TDWTF posts has warped my fragile little mind.Damn. I wrote a great reply to the OP but it ended up on a different thread.
SLAAAPPPfatdog backhand slaps DOA
See how this works?
-
@DOA said:
Damn. I wrote a great reply to the OP but it ended up on a different thread.
Can you at least link to it?
-
@Spectre said:
@DOA said:
Damn. I wrote a great reply to the OP but it ended up on a different thread.
Can you at least link to it?
WHOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOSHHHHH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-
@tster said:
WHOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOSHHHHH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Dagnabbit. And I can't even blame it on the lack of morning coffee.
-
@morbiuswilters said:
"Mac user". Nothing you can say is taking it too far
Can one take it any further than "Mac user"? To my knowledge, anybody that at least two unwebbed fingers on one hand and an IQ over 50 should be able to use a two-button mouse without a problem. It really says something when a person needs an OS dumbed down to use a single-button mouse. Not to mention that the prepending of lower-case "I" to product names seems to attract these people like moths to flame.
-
-
That's not necessarily stupidity. It is probably fair to call it ignorance. Also, it seems like the kind of argument that would be made in design phase. In that phase, one might make the argument that the way Windows handles callbacks makes it difficult, so the Windows message passing infrastructure should be used instead.
But what this guy is saying is not stupid in the overall sense. He is quite likely correct that you guys have wrestled with the fact that callbacks occur in a different thread. Some of you probably didn't even realize this at first. His suggestion to use the message passing infratructure to enforce sychronicity is a logical one, which may or may not apply to your situation. It may be a trick that you can put aside for application later.
In my experience, novice programmers force things into a single thread out of ignorance. Slightly more advanced programmers look for opportunities to use multithreading and find them everywhere. But truly advanced programmers know the value of keeping things in a single thread and use multithreading with great care.
See http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf if you really want to understand all of this (as opposed to complaining about it on this increasingly lame site, which seems to be targeted at the $15/hr crowd)
-
@bridget99 said:
See http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf if you really want to understand all of this (as opposed to complaining about it on this increasingly lame site, which seems to be targeted at the $15/hr crowd)
I started reading the PDF but I stopped after reading this paragraph
@The problem with Threads said:
Threads, on the other hand, are wildly nondeterministic. The job of the programmer is to
prune away that nondeterminism. We have, of course, developed tools to assist in the pruning.
Semaphores, monitors, and more modern overlays on threads (discussed in the following section)
offer the programmer ever more effective pruning. But pruning a wild mass of brambles rarely
yields a satisfactory hedge.
To offer another analogy, suppose that we were to ask a mechanical engineer to design an
internal combustion engine by starting with a pot of iron, hydrocarbon, and oxygen molecules,
moving randomly according to thermal forces. The engineer’s job is to constrain these motions
until the result is an internal combustion engine. Thermodynamics and chemistry tells us that this
is a theoretically valid way to think about the design problem. But is it practical?
To offer a third analogy, a folk definition of insanity is to do the same thing over and over again
and to expect the results to be different. By this definition, we in fact require that programmers of
multithreaded systems be insane. Were they sane, they could not understand their programs.Have you actually read this and agree with it? First analogy is very lame. Just look at English landscaping.
Second analogy is completely on the wrong level. The engineer constructing an engine does indeed need to make sure all actions are synchronized. e.g. you can build all the parts in parallel, but suppose you have only one workshop, you will have to control access to it because it is a global resource.
And for the third: every single multi-threaded application/library I have written has always given the same results for the same input. Sometimes the internal sequence is different but the end-result is consistent. So insane people do things differently every time but expect the same result?
-
@bjolling said:
I started reading the PDF but I stopped after reading this paragraph
I've scanned a little more, and suggest that you continue reading in spite of this unfortunate tangent of insane metaphors.
The author essentially argues that threading in its current forms and implementations quickly leads to execution spaghetti, and despite the tools to untangle the mess, there should be a simpler way to implement and use threads that prevent spaghetti from the get-go.
I've never explicitly used threads, so I don't judge that premise, but that's what's in the text and it seems completely reasonable.
-
@dhromed said:
I've scanned a little more, and suggest that you continue reading in spite of this unfortunate tangent of insane metaphors.
Hmmm.... starts getting more interesting as from chapter 5. At least the author starts to capture my imagination on how to solve the common problems of multi-threaded design. Let's give him a chance
-
@dhromed said:
Also he wants a pony.The author essentially argues that threading in its current forms and implementations quickly leads to execution spaghetti, and despite the tools to untangle the mess, there should be a simpler way to implement and use threads that prevent spaghetti from the get-go.
@dhromed said:
I've never explicitly used threads, so I don't judge that premise, but that's what's in the text and it seems completely reasonable.
*shrugs* Complex system is complex.
-
@dhromed said:
The author essentially argues that threading in its current forms and implementations quickly leads to execution spaghetti, ... there should be a simpler way to implement and use threads that prevent spaghetti from the get-go.
I haven't read the PDF, but I'd have to agree that if threading methods result in spaghetti there is something severely wrong: the use of threads should result in textiles, not foodstuff.
(I'm starting to think that if tokens used to create source files had to be mined from the ground, all the bad programmers would disappear. Tinkering with code is far too inexpensive compared to matter-bashing activities. At least in matter-bashing people understand you have to do some up-front planning to avoid embarassing wastes of physical resources. Or maybe we should espouse some method of making the lack of planning in software is equally embarassing.)
-
@DaveK said:
@dhromed said:
I've never explicitly used threads, so I don't judge that premise, but that's what's in the text and it seems completely reasonable.
*shrugs* Complex system is complex.The current paradigm of thread management makes things far more complex than is necessary.
-
@morbiuswilters said:
@DaveK said:
@dhromed said:
I've never explicitly used threads, so I don't judge that premise, but that's what's in the text and it seems completely reasonable.
*shrugs* Complex system is complex.The current paradigm of thread management makes things far more complex than is necessary.
I think modern object oriented languages do it fine. All you need to do is ensure thread safety at the correct level of abstraction. If you make sure that your objects are thread-safe then there usually isn't much else you need to do. If you find that you are needing to co-ordinate thread safety between objects then I would say that your design is flawed in some way.
-
@tster said:
Much fear of threads in author of PDF I sense. When describing threads he goes very very low-level just to prove that it's a mess ("execution spaghetti"). But when he proposes his solution he immediately jumps to high-level ("coordinating language")@morbiuswilters said:
@DaveK said:
@dhromed said:
I've never explicitly used threads, so I don't judge that premise, but that's what's in the text and it seems completely reasonable.
*shrugs* Complex system is complex.The current paradigm of thread management makes things far more complex than is necessary.
I think modern object oriented languages do it fine. All you need to do is ensure thread safety at the correct level of abstraction. If you make sure that your objects are thread-safe then there usually isn't much else you need to do. If you find that you are needing to co-ordinate thread safety between objects then I would say that your design is flawed in some way.
tster is right. I follow a few simple rules in OO to make multi-threading work and they have never failed me, such as:
- Avoid globally used objects, singletons, static stuff and the like. For example .NET is designed for fast object creation so just do a 'new'
- Don't pass a reference to an object to different threads but make a deep-copy.
- Identify your global resources and protect/synchronize functions that change their state. Avoid deadlocks by re-using the same locking object between objects that closely work together
These are just general guidelines that I use and they work for me. I'm sure you guys can come up with more of those.
-
Also don't forget that threads are themselves an abstraction that can very well represent the process being implemented.
One reason I like to use seperate threads for call-backs is it makes the various callback functions non-dependant on one another. For instance, if one of the callbacks does something that takes a long time, we don't want to make all the other callback functions waitfor it to be called. Furthermore, if the developer has all callbacks coming sequintially from a single thread, then he might accidentally develop dependancies on the order of the callbacks. This can be avoided by having multiple threads since this kind of thing would turn up during debuging and testing. Better that, than have a library change down the road and all of a sudden your app is crashing or giving incorrect data because someone got an updated DLL installed with Age of Empires 4: The age of threads.
-
what should i suggest for it, let me think ???
-
I read something today that brought this topic to mind (http://www.concertant.com/Presentations/euroPython2009_GILIsntEvil.pdf).
The article questions threads-as-a-model in a way that reminded me of the Edward Lee link I originally posted here. This one is by a PhD also.
My favorite quote: "Threads are dead. Long live processes."
-
How does he expect you to callback to the original thread? The only way to achieve this is for the original thread to poll it constantly waiting for an answer. If this was the norm it would make threading usless to essentially block one while waiting.
-
@darren71 said:
How does he expect you to callback to the original thread? The only way to achieve this is for the original thread to poll it constantly waiting for an answer. If this was the norm it would make threading usless to essentially block one while waiting.
I don't know exactly what the OP's maligned coworker had in mind. But the most obvious way to take a callback function and force its execution into the "correct" thread in Windows is to post a message. Many threads are "pumping" a message queue in Windows anyway.... yes, this does involve a form of polling. Consider the cannonical Windows message loop:
while(GetMessage(&Msg, NULL, 0, 0) > 0)
{
TranslateMessage(&Msg);
DispatchMessage(&Msg);
}GetMessage() will sit in a loop periodically checking (i.e. polling) for a message until one arrives.
This seems inefficient, but so many Windows threads will need to be doing this anyway. The "main" thread of any app with a GUI will constantly be running this loop, as will any apartment-threaded COM objects running in a "free" caller thread. So, relying on such a loop is not bad... it's just a part of the Windows infrastructure, at a fairly low (i.e. fast) level. Relying on these loops is the best synchronization architecture in many cases. Message passing eliminates a whole category of errors, e.g. race conditions occuring in the execution of out-of-thread callbacks.
You are right to worry about the possibility of multithreading-without-parallel-execution, which is more common than people realize. But in this case, I think that there is still real parallelism in the system. The "original" thread can make a call that will eventually result in a callback, and then continue doing other things. The callback function can simply post the message without waiting for its analysis by the original thread, by using a call to PostMessage().
I stand by my original analysis that the "stupidity" in this case is really just good advice... any multithreaded process needs to be synchronized and message-passing is a good approach.
-
@bridget99 said:
@darren71 said:
How does he expect you to callback to the original thread? The only way to achieve this is for the original thread to poll it constantly waiting for an answer. If this was the norm it would make threading usless to essentially block one while waiting.
I don't know exactly what the OP's maligned coworker had in mind. But the most obvious way to take a callback function and force its execution into the "correct" thread in Windows is to post a message. Many threads are "pumping" a message queue in Windows anyway.... yes, this does involve a form of polling. Consider the cannonical Windows message loop:
while(GetMessage(&Msg, NULL, 0, 0) > 0)
{
TranslateMessage(&Msg);
DispatchMessage(&Msg);
}GetMessage() will sit in a loop periodically checking (i.e. polling) for a message until one arrives.
This seems inefficient, but so many Windows threads will need to be doing this anyway. The "main" thread of any app with a GUI will constantly be running this loop, as will any apartment-threaded COM objects running in a "free" caller thread. So, relying on such a loop is not bad... it's just a part of the Windows infrastructure, at a fairly low (i.e. fast) level. Relying on these loops is the best synchronization architecture in many cases. Message passing eliminates a whole category of errors, e.g. race conditions occuring in the execution of out-of-thread callbacks.
You are right to worry about the possibility of multithreading-without-parallel-execution, which is more common than people realize. But in this case, I think that there is still real parallelism in the system. The "original" thread can make a call that will eventually result in a callback, and then continue doing other things. The callback function can simply post the message without waiting for its analysis by the original thread, by using a call to PostMessage().
I stand by my original analysis that the "stupidity" in this case is really just good advice... any multithreaded process needs to be synchronized and message-passing is a good approach.
This is fine if we were talking about an application that had a message pump. In this case, we are talking about an API that talks to our back-end servers to receive prices. Him, the consumer of the API does have the ability to post it back to the main thread and I suspect this is what he did to overcome his issue.
The API in question takes the packet of data received over a socket and calls a user defined callback. The callback itself is not threaded and as such until the callback completes there is no need for the API itself to worry about how the consumer of the data will use it.
Again, I suspect that he did post back and that is a requirement of his application. My real issue was his demanding that I call the user-defined callback back on his main thread. As I am the developer of the API, I do not feel it is my responsibility to modify my code to adhere to his development standard.
-
@Hellweek said:
My real issue was his demanding that I call the user-defined callback back on his main thread. As I am the developer of the API, I do not feel it is my responsibility to modify my code to adhere to his development standard.
If he's just providing you with a function pointer, then I think you've got a legitimate complaint and I retract any implication otherwise. If he gives you a function pointer, there is not much you can reasonably do with that besides execute the function in your own current thread. The Windows pattern is that callbacks requested by passing around function pointers are going to get called in another thread. There is a Windows pattern for automatic marshalling of the sort your co-worker wants - the single-threaded apartment - and maybe you guys would benefit from it. But you're absolutely correct that the interface you're providing your coworker (and the associated responsibilities) are in line with Windows practices. (I won't call these "best" practices, but they should not be unfamiliar to a real Windows programmer.) And as much as I've probably critized COM over the years, it does serve as a sort of referee in this sort of processing model "pissing contest." Unfortunately, it refuses to referee such things as memory allocation for strings, type safety, etc.
