|
There's no such thing as a PCI "port". There's the PCI expansion bus, which you normally never talk to. You talk to the devices on it directly. Same thing with USB.
|
|
|
|
|
|
|
I have looked at System.Transactions but was unsure if this would accomplish my goal. If this is the way to go, do you know of any good examples of how to implement this? I've been reading through that page for sometime but can't quite figure out how to get a working solution.
Thanks for the response
|
|
|
|
|
Try here[^]
only two letters away from being an asset
|
|
|
|
|
Hi all
I am trying to uninstall from the GAC an assembly.
I use gacutil /u MyAssembly.dll
Once I have done this, I expect that in
c:\Windows\assembly
MyAssembly.dll is gone,
but is still there.
What I am doing wrong?
Thanks
Man
|
|
|
|
|
I don't know if this is the cause of your problem, but gacutil (on MSDN)[^], read the third paragraph on the '/r' option in the err... Options table.
Hope this helps!
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
All you did was unregister the .DLL. It won't remove the .DLL file from the folder. You have to remove that yourself.
|
|
|
|
|
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??
|
|
|
|
|