|
Go to window/assembly folder . Right click on your installed assembly and select unstall option from menu. Assembly will be uninstall along with remove from registry.
|
|
|
|
|
How do you bulk multiple INSERT statements? Suppose I fire a bunch INSERTs in the form of SqlCommands, how do I make the server execute them in one batch, rather than one by one? Is there a simple solution, or do I have to drag the entire ADO.NET library into the picture?
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
There's a bunch of examples of this out on the web. All you have to do is search[^].
Also, you might find this[^] to be quite interesting.
|
|
|
|
|
Yeah, I found those, but they all required me to use the whole ADO.NET stuff. I found some code from the nHibernate project that I'm going to use instead.
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Have you look at LinqTOSQL or Entity Framework?
only two letters away from being an asset
|
|
|
|
|
Indeed I have, which is why I'm looking for batched inserts. 
Oh well, I found a really good solution (mentioned above) that will cover my needs. I'm going to keep the Linq to SQL code (commented out), if they ever optimize inserts.
I just did a comparison using Linq to SQL and the nHibernate code, and the difference was staggering. 20+ seconds compared to less than a second (I have no quantitative figures here, but let's just say that I never say the progress bar). Now I have about 30 entities or so to convert into the new scheme... 
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Jörgen Sigvardsson wrote: 20+ seconds compared to less than a second
I assume you mean LinqToSql vs. nHibernate?
only two letters away from being an asset
|
|
|
|
|
Yeah. Well, not nHibernate as is. They have this SqlCommandSet that can batch SqlCommands together.
Linq to SQL is only really useful when editing and querying small amounts of objects, IMHO. That's mostly the case for me, but this is a special case that needs to be adressed. Damn shame I can't do it in pure Linq.
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Together with reading Joe Duffy's 950 page comprehensive guide to "Concurrent Programming in Windows",
I recently came across the following website that cleared the fog from my eyes as to what is going on in a multi-threaded application:
http://www.albahari.com/threading/
Reading all this in detail and coming to terms with the implications, highlights a major concern I have as a professional developer about building anything at all using multi-threading.
With a simple single threaded application any developer can reliably design class diagrams and simple flow diagrams for example, and reliably test it by stepping through a known and predictable path of execution and running it just once. The paths of execution are known and can be throughly tested.
The whole assumption of multi-threading has been you know exactly what you doing and always get it right. You will get no help from the compiler, you get a random path of execution due to the thread scheduler's non-deterministic (random) behaviour, all the error handling and logging in the world will never once tell you that you missed a single lock in a million lines of code. In fact, there is no tool available to test multi-threading in shape of form at all!
Once you've installed the application, when you get unexplained crashes, you can debug by stepping through the application with the same data that created the error and not once ever find the error as there could be millions of paths of execution, which is the weird behaviour every developer has felt stepping through the application time and again, jumping from thread to thread, but never in the same place twice!
Given that we can't reliably design and test an application with multi-threading, why on earth should anyone expect that we can build reliable applications with it?
Even if I now felt confident enough to now go build a multi-threaded application, no matter how well I designed it, any future errors introduced by another developer would never ever be found.
If that doesn't scare you enough, I (or anyone else!) could take look through your code, remove any single lock in a million lines of code and all the exception handling and logging and testing in the world will never help you find one of the simplest types of multi-threaded errors, let alone any of the vastly more complex defects that can occur!
Once you understand that missing locks on static data values can lead to corrupt data, i hope you feel as uneasy as i do.
I would like someone to challenge my assertion that .NET multi-threading undermines the ability of developers to produce reliable applications with reliable data.
This strikes me as a fundamental flaw in most developer's assumptions of what we up against and a fundamental flaw with multi-threading as there is no way to reliably to design or test for multi-threading errors. There is equally no way to even find the source of any errors when we get unexplained crashes or random data, and that is assuming you even realise yet how high I expect the probability is that you already have random data given the staggering complexity of this architecture and how hard it is to get right without any help from any normal tools that developers have come to depend on!
|
|
|
|
|
Justin Fox wrote: Given that we can't reliably design and test an application with multi-threading, why on earth should anyone expect that we can build reliable applications with it?
A thread is a single path of execution, for example, the actions that you perform. We can test this list of actions like it's a single thread.
Put more people in the room, and you'll get a problem with shared stuff. For example, if I enter the room then you'd best not touch the coffeemachine.
You can test my path of actions, you can test your path of actions, but you'll have to lock the coffeemachine because you can never know when our two lists of actions collide (we might grab the coffeemachine at the same time).
|
|
|
|
|
It's not so much a flaw of multithreaded applications, as it is a flaw in designing applications that rely on side effects. Have a look at the work that Microsoft are doing in Axum[^], to see why multithreading requires a complete shift in the way you look at developing applications.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
I should clarify that the newer ways of working with threads the .NET have introduced, such as Background Worker threads, PLINQ, etc, ensure that there is less expected of the developer, so using these new options appear to be far more controlled, so I should have made that more clear up front.
When to use threads and when not to as highlighted in www.albahari.com/threading is something I will be following in future.
My concern is around the use of allowing someone to spawn new Threads everywhere without something to check what he is doing and identify how bad it gets very quickly! Add in a mix of synchronisation, but also mis-applied, with extra dependancies to other classes and extra sleep delays to compensate for being completely in the fog, and it produces the perfect application where defects lurk in ever corner, but don't get detected until run in live production a million times over!
|
|
|
|
|
I think you're blowing this WAY out of proportion.
You make is sound as though you're walking through a dense minefield every time you think of launching a new thread. That's just not the case. If you understand how to do threading properly and take the proper precautions around making sure that shared access is properly maintained, you'll never have a problem. All of the horror stories you here over this are because things were not done properly or something was missed along the way and an avenue of potential failure was left in the code.
With proper planning and thorough investigation, this isn't a problem. There are thousands of multi-threaded apps in production that never have an issue. So what are you worried about?? The only thing that's scaring you is that you haven't done it yourself and your skill set doesn't include the knowledge of how to manage proper threading.
|
|
|
|
|
I fully recognise there are whole teams of developers out there that can design flawless designs knowing they need to keep it simple. Equally, I recognise that there are plenty of other simpler options for most cases that you practically roll out the box. That is fine and I recognise that I will be getting responses from developers who do know way more than me on this. Fine.
What about when you come across an over complex design that you know to be flawed where clearly the designer didnt realise that it is a seriously bad idea to just spawn threads everywhere? Are you so sure that you want to turn a blind eye just because the compiler doesnt throw any errors and all your error handling reports nothing? How confident would you be over your data? Can you trust that some other junior doesnt come alone and unknowingly just add some static data? And that no matter how many times you point out how fundamentally flawed a design is to a manager, since there is no evidence of an error, there is no error?
Am i making any sense?
|
|
|
|
|
I don't think it's a matter of "turning a blind eye" to potential problems. This is where proper mentoring and supervision come in, along with design reviews, code reviews, checkin buddies, unit tests, continuous integration etc. etc. In fact, with modern approaches to design and development, it's a lot easier to produce reliable multi-threaded systems than it was say 20 or 30 years ago.
To use a simile, it's like building a suspension bridge - you make sure the designs are checked and re-checked, and that calculations and simulations run multiple times. Or, if you want to compare the lone developer mode, if you're building a garden shed, you'll make sure it's put together properly, step by step.
Like it or not multi-threading is here to stay[1] and it really is the only way to build properly interactive and/or networked applications. The project (very large project) I'm on at the moment is making extensive use of threading and we very seldom have any problems due to it - mostly problems arise within threads. Getting it right is a matter of good design and good control over how the system is put together.
In fact, nearly everything I've worked on over the years has been multi-threaded / parallel-processing, and I reckon, as with the current job, inter-process problems have been in a very small minority.
OK, threading can bite you unexpectedly, but just remember "let's be careful out there"...
[1] "here to stay" - was it ever away? Multi-threading has been around since pretty much the beginning of computing, and even interrupt servicing could be thought of as a separate thread.
There are three kinds of people in the world - those who can count and those who can't...
|
|
|
|
|
I follow everything everyone keeps highlighting about how this has been around for years and is used everywhere.
I just wish this had all come with a health warning, because, no matter how many people tell me they've used it for years, I have come across people who unfortunately still under the illusion that multi-threading is the silver bullet to increase performance (talking single core here as this is what they've always believed.) Never mind that a clumsy design includes enough delays to probably falsify any such suggestion anyway! If someone's understanding of OO re-useability stopped at inheritance, how much are they going to know about design patterns and anything sensible about multi-threading? Some companies are run by managers not developers (if you know what i mean), which I think is unfortunate and a bit scary given the tools that are used without thought...
|
|
|
|
|
Justin Fox wrote: no matter how many people tell me they've used it for years, I have come across people who unfortunately still under the illusion that multi-threading is the silver bullet to increase performance
You just said it yourself, though the words are slightly out of order. Multi-threading gives the illusion of increased performance.
Justin Fox wrote: Never mind that a clumsy design includes enough delays to probably falsify any such suggestion anyway! If someone's understanding of OO re-useability stopped at inheritance, how much are they going to know about design patterns and anything sensible about multi-threading? Some companies are run by managers not developers (if you know what i mean), which I think is unfortunate and a bit scary given the tools that are used without thought...
OK, so what's the whole point of all this?? Scared of a bunch of idiot developers and the crap you may get stuck supporting??
|
|
|
|
|
Justin Fox wrote: I fully recognise there are whole teams of developers out there that can design flawless designs knowing they need to keep it simple. Equally, I recognise that there are plenty of other simpler options for most cases that you practically roll out the box. That is fine and I recognise that I will be getting responses from developers who do know way more than me on this. Fine.
Guy, I've done dozens of times without running into any issues like you're describing. And I'm a team of 1. Noone checks my work over but me.
Justin Fox wrote: What about when you come across an over complex design that you know to be flawed where clearly the designer didnt realise that it is a seriously bad idea to just spawn threads everywhere?
Scrap it and rewrite it properly. Don't try and give me that argument that it "costs too much." It costs WAY more to do it badly and have to support it then it does to scrap it and redo it from scratch.
This is also where teams of people come into play checking each others works and designs. If you don't have a threading expert sitting around your shop, hire a consultant to check over the work.
Justin Fox wrote: Can you trust that some other junior doesnt come alone and unknowingly just add some static data?
I don't trust anyone. Even the guy I sit next to every single day.
Justin Fox wrote: And that no matter how many times you point out how fundamentally flawed a design is to a manager, since there is no evidence of an error, there is no error?
At that point, the accountibility stands with the manager, not the putz who wrote the code. If the manager want to release sub-par quality like that, well you're just going to have to stand up for yourself.
|
|
|
|
|
You talk of this as if it is something new. Almost every OS since the dawn of time has relied on multi-threading just to run the simplest systems. I wrote my first multi-threaded program in about 1969! I think Eddy made the point earlier that all you need to do is stick to the simple rules:
1. If an object is shared across threads then it must be locked and unlocked as appropriate.
2. If you don't understand threading then don't use it.
|
|
|
|
|
Agreed on your 2 points, and I feel confident in a clean and simple design this is straight forward.
Ever come across a design involving one thread calling into a class that itself calls back - cyclic redundancy that i spotted on day 1. Manual reset signalling on both sides, waithandles, and quite a few other dependancies that at a high level are immediately identified as making it unstable. Feels like this would just chase its tail and make one dizzy - hard to spot the intent of the design except to say its clumzy and most likely flawed, but lots of work to do if one actually needed to dead certain it was not going to bite you in your sleep!
I think you would be amazed who is sometimes given the firecrackers to play with!
Constructively, is there any simple technique for testing or verifying correctness of design?
|
|
|
|
|
Ok, ok.
I retract my assertion in its current form.
I really didn't expect developers to be so complacent about this given what I have seen, but that probably explains the difference in the type of places we work.
I think the only thing I've managed to prove is that the type of developer that takes an interest in understanding how to design good software and takes the time to read forums like this can probably be trusted to build a really sound and reliable threaded application.
I would like someone to consider another planet of development though, where arbitary timelines are based on the complexity of the business problem, which of course is not the same as the complexity of the implementation that developers face (if this makes any sense). The only thing that matters is making the deadline and anything that cannot be detected as an error is most certainly not even a consideration.
My preference in some organisations would be to keep the crackers in the box and use more appropriate solutions to simple problems, rather than allowing unnecessary complex solutions to be tampered with by any unsuspecting team member.
I'll close this message, unless there are any other comments.
|
|
|
|
|
Threading techniques have a purpose; here are the two main reasons AFAIK.
1. Organizational asset.
Threads can be used to keep things clearly separated, by hiding them inside some classes, and making sure the threads, their locks and their shared data is not publicly accessible. Imagine an app needing to communicate with two serial ports; you either have to poll a lot, which is wasteful, or you assign a thread to each serial input, which can be neat and simple.
2. Performance asset.
Threads can be used to improve performance: any time your CPU is not running at 100% chances are your code is waiting on something instead of working on some other part of the same job, and that is where threading can help.
You may feel reluctant to use threads as you aren't sufficiently familiar with them; the same could apply to files, to databases, to regexes. You need to know them to use them properly. Files may seem easy, databases may be more difficult to get good performance, threads may frighten you. It all depends on your needs and your skills. And everything can be abused when you don't really understand the basics. Bugs are always possible, discipline, creating small entities, and performing tests (unit and other) should overcome most of the problems.
Luc Pattyn
Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.
Local announcement (Antwerp region): Lange Wapper? Neen!
|
|
|
|
|
The main problem with threads, judging by some of the questions/comments I have seen here on the CP forums, is that people use them without fully understanding their primary purpose (as so clearly described by Luc above). Like any tool they can solve some problems, but in the wrong hands, or used the wrong way, they can wreak havoc.
|
|
|
|
|
Threading in general doesn't faze me, provided that it is clear which aspects of libraries are thread-safe and which are not. The biggest key is to make sure that there are clear boundaries of interaction between threads. For example, a particular thread whose job is solely to receive commands from a TCP port and place them into a queue structure. The queue structure is thread-safe, and the application code is prepared to deal with data from different TCP ports arriving interleaved, so I don't worry about detailed interaction between threads.
What has made me paranoid is reading about how IA64, unlike other systems, does not guarantee cache coherency between processors in the absence of explicit interlocks. Unless programs default to only running on a single processor, that seems like a sure-fire recipe for random non-reproduceable and non-trackable bugs unless someone can come up with a way to ensure that code which doesn't use proper interlocks on memory accesses would be very likely to fail (e.g. by rigging things so a non-interlocked write by one processor will have a 50% chance of showing up in a non-interlocked read by another, rather than having in some cases a 99.99% chance).
I suppose in one sense an architecture isn't "broken" if it conforms to specifications. On the other hand, I would consider a specification broken that would allow the following 'thread2_test' to yield a value of 0x12340000.
volatile int val1, val2;
void set_val1(void)
{
val1 = 0x5678;
}
void thread1_main(void)
{
set_val1();
val2 = 0x1234;
}
int thread2_main(void)
{
int read1,read2;
read1 = val1;
read2 = val2;
return read1 + 65536*read2;
}
From my perspective, it should not be unreasonable for a programmer to expect that all side-effects from a function call will have completed before any statements following the function call are executed; even if a function is inlined, a compiler should still enforce that. By my understanding, however, when running .net on IA64 such behavior is not guaranteed. If thread1_main and thread2_main are scheduled to start simultaneously, there is no guarantee that thread2 won't see val2 get written before it sees val1 get written. How can one realistically write bulletproof code on such a system?
|
|
|
|
|
supercat9 wrote: By my understanding, however, when running .net on IA64 such behavior is not guaranteed
I'm not exactly sure, but, the CLR specs seem to guarantee more than IA64 - doesn't mean that it would just have to Make It So regardless of the underlying architecture?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
