Recommend book for learning VB.Net 4.0 incl. multithreading

Hi Folks

I have been using VB on and off for some time in an amateur/incidental manner, pretty much picking it up as I go along, which has served me well enough until now.
I can write a program with a few classes, some ADO usage and get the GUI to do what I want.

However I am now working on a project that requires a bit more formal of an approach, so I though maybe a good book would be a good place to start.
The project's main requirements is the use of multi-threading and that DB queries be reasonably efficient.

Thus I need recommendations for a good book that doesn't assume too much initial VB knowledge (i.e. not a reference book but an actual "teaching" book) that does provide some of help with the basics (how to separate logic or how to properly use namespaces, for instance), but that also covers things like LINQ, pLINQ, multi-threading, resource sharing, etc, it would be great to find one book that does it all :).


As an example, looking at the MSDN site I did see Alessandro del Sole's "Visual Basic 2010 Unleashed" book which seems to have a description that mentions the right areas, but some reviews do remark that it can be a bit reference-y...

Thanks :)

PS: Oh, I need to use Ethernet and UDP comms as well and know very little about using them properly either!

Quote:

---

Originally Posted by wolf99

The project's main requirements is the use of multi-threading

---

That's a technical solution, not a requirement. What are the actual requirements that make you think you need multi-threading? Is it concurrency, parallelism, etc? Threading is hard and if there are other solutions to your requirements then it would be wise to consider them. If you explain a bit more, we might be able to suggest other techniques that are far safer.

I totally agree with Evil_Giraffe here. Listing technical solutions as requirements is a disaster waiting to happen. I can tell you horrible stories of a lot of various projects that have totally failed because some genius started out with the technology and tried to fit in the solution with the technology instead of actually listing the real requirements of what the system/application really need to accomplish and then selecting the best technology to solve the problems.

However you asked for a book recommendation, I personally don't shop for that many books any more since the problem with printed books is that it takes a long time writing a book and technology move so fast. So most professional books are written based on early beta versions of the software so that they can be printed and on the shelves when the new version of the particular technology or software is released.

However I have read Visual Basic 2010 Unleashed and I liked it a lot, but in all honesty I'm also a bit bias here since Alessandro also is a good friend of mine, but I still think it's a good read.

The bottom line is however that learning new techniques is a good thing but you should never ever base your projects on a specific technique or technology simply because that technique or technology exists or just because it might be the latest buzz word. Always list the actual requirements as they are seen from the users perspective, after all the end-user doesn't care which technology you've used as long as it works and works well, and only after that start thinking about what technology you should use. If part of the solution would be best served with multiple threads then obviously you should use it. However I have multiple times said that threading is usually abused. Think about it, what should be the main reason to use multiple threads? Answer: When you really need concurrency! In other words when you need the CPU to do multiple things at the same time so you need more than one CPU core to work for you.

However people often spin up new threads to do IO work, but that is not CPU intensive work, most of the time the CPU will not do any work at all during these tasks, it will just sit and wait for the IO task to complete. In these cases you don't need concurrency or parallelism, what you need is asynchronous execution, which might be solved by invoking a new thread but doesn't necessarily have to rely on it.

Quote:

---

Originally Posted by Evil_Giraffe

That's a technical solution, not a requirement.

---

I stand corrected :)

The project is at its core a scheduler that has jobs of work logged to it that need to occur at a certain time. It acts as a controller of a set of devices connected by raw TCP/IP connections.

A job will generally consist of grabbing an object from a list, a DB read and a several raw TCP/IP writes and reads to a particular device, followed by a DB write and a change to the GUI to show progress.

As the jobs can be scheduled for any time, they can occur at the same times. Also there is another type of job of work that needs to listen for and handle unexpected talking (from devices that request service), thus, I guess, there is parallel read/write to the DB and different TCP/IP connections.

I have had a stab at this already, and I managed to get a scheduler class that I think would work as needed, but my research on threads/tasks has been limited to MSDN and "starter" tutorials that dont really answer a lot of the questions I have or provide a concrete manner for deciding which way to do things in this regard. I do have lots experience with embedded C, some with RTOS's so I have a bit of a handle on the concept of tasks and resource sharing etc, it's just a mtter of understanding the best way of doing things for my particular project and what the syntax should be and so on.

As I suspected from your mention of networking and DB, I'd definitely try to avoid threading here and go asynchronous. Think about two tasks that are both scheduled for 2:00pm; you say they should execute at the same time so you need threading, but consider this: If you have a single CPU you still won't have them executing at the same time, they will take turns using the CPU to execute their code. In an asynchronous world, you'll not have that interleaving of machine instructions, but say you execute a few lines of code and then run a DB query. One of the tasks is going to run before the other, and spends less than a microsecond executing the lines of code and then calls the database. As soon as that database call is made the task can't do anything more so the next task is started, spends less than a microsecond running code and then starts a database call and stops working. Some thousands of microseconds later the database returns the results of one of the queries and that task gets to do its post DB processing for less than a microsecond. At some other point the other task's query returns results and spends less than a microsecond doing its post DB processing.

As far as the user is concerned, both tasks executed at the same time.

[ Edit: Oh yes, about the book recommendation, I'm afraid I don't use books either, but I'd be surprised if you could get a book that went from as basic as namespaces all the way up to how to build a whole system of the type you're describing :S I think you may need a few different books, and at the "advanced" end I'd suggest a technology agnostic book to understand the principles (e.g. GoF's Design Patterns) and then use online references to the particular technology you choose ]

There is a good book on multithreading that I read. I believe it's called something like Concurrent Programming in Windows by (perhaps Joe) Duffy. It covers how the OS handles multithreading from pre-XP through at least Vista, and how that is exposed by languages, including the CLR underlying .NET. However, it was written before the Task library and so it doesn't get into any of that at all. It does, however, take up some 800 - 1000 pages, so it isn't light reading.

Quote:

---

Concurrent Programming in Windows by (perhaps Joe) Duffy

---

Aye, that's the feller! It's not cheap either (no computer book ever is) and it's aimed at C# and C++ so if you're a VB only kind of wolf, it's probably going to be really hard going.

No, it won't be...at least not for that reason. While it is kind of aimed at C languages, that really doesn't matter all that much. The book is mostly text with relatively few code dumps, and those code dumps are generally pretty small and easy to understand and/or can be ignored. The writing is more clear, and the code that is there is generally well explained.

As a programming book, I find this to be one of the better ones I have read largely because the author seems more focused on thoroughly explaining the subject rather than thoroughly padding the page count with extensive code dumps. On the other hand, threading is a HARD subject. In fact, I consider it to be on the edge of human capability. Trivial threading is generally not too bad, but threading has such potential complexity that if you get into really complicated threading scenarios, I feel that they are probably above the ability of even an above average person to get it 100% right. For one thing, this is why pretty much everybody suggests that you measure the performance of threaded solutions to make sure that they are actually superior to the single-threaded alternative. Because the lock contention, thread convoys, and other things, it is possible to slow a program down with threading rather than speeding it up, and it is possible to do so unwittingly. If it was always immediately obvious that threading would provide huge benefits, nobody would suggest that you performance test all threading, but in reality, everybody suggests that, so it can't be so obvious whether or not you will benefit from some kind of threading.