Thanks,
Josh

Yes. If the API you’re using is written properly, you don’t need a finalizer. The reason for this is that, as soon as your “wrapper” class would be finalized, any managed references (the internal API handle) are also eligible for finalization, and the IDisposable implementation there should handle the closing automatically.

Adding a finalizer in your class would really have no effect, and just decrease performance.

If, however, you are finding that the connection is not being closed because the internal implementation is written improperly, you could add a finalizer and close it explicitly – but this really shouldn’t be required.

-Reed

if (part.ExportDefinitions.Any())
{
throw new ArgumentException(string.Format(CultureInfo.CurrentCulture,
Strings.ArgumentException_TypeHasExports, part.ToString()), “part”);
}

An explanation would be greatly appreciated!

Thank you very much for your commitment to the developer community.

I am still wrangling with what to do in my particular situation…
I have written a class that encapsulates API functionality for an external system. Creating the connection is costly — consistently takes 6 to 7 seconds to connect — so I am creating the connection in the constructor and leaving it open for the object’s brief lifetime (it is for a web application). (During its lifetime, several methods are repetitively called, and performance would be horrible if I opened and closed the connection within each method.)

The API object does have a Disconnect() and Dispose() method and I am exposing my own Disconnect() method and implementing IDispose. Good form would be for the user of my class to always Disconnect() and Dispose(), but of course there is no way to guarantee that will happen.

From what I’ve read, it seems I can assume that the API object itself will be disposed of on its own since it is a manged resource. Would that be correct?

More importantly, however, I do want to be sure that connection is always explicitly closed first. Even though I have no unmanaged resources, is this a case where a destructor is definitely needed? And I assume that I would check for and close the open connection regardless of whether Dispose(bool) was called with True or False?

If you have sample code that illustrates this scenario, that would be awesome:
1. Class (can be sealed if that helps) with a private class-level variable that contains an open connection to something (connection made in the constructor).
2. The Class exposes Disconnect() and implements IDispose.
3. Code is in place to reliably ensure that the connection will be closed if the user of the class neglected to do so.

Another thing I wonder is, do I need to implement IDispose at all? Is it dangerous/stupid to assume that the API object is smart enough to internally close the connection itself when it is disposed/finalized?

Thank you again!

It’s definitely something you need to take into consideration in the design. There are really two options here – and the best depends a bit on how you’d want your library to be used.

If the library provides a high level of abstraction, you might want to use the TPL within your library to allow the performance gains available to surface. However, if its a lower level API, it could easily be better to design your library to be thread safe, so the caller can parallelize as needed.

-Reed

Partition your problem into enough tasks to keep each processor busy throughout the operation, but not more than necessary to keep each processor busy.
Partition your problem in a way to place the most work possible into each task.

So if I am making a library for re-use, are their any design considerations I need to take into account before using parallelism? For example, if I am using my library to accomplish some tasks and I feel that doing these tasks in parallel would improve performance, will I experience a performance decrease if I use TPL because of my library?

Thanks,
Chris

Thanks again,
Chris

I was banging my head trying to get the UI to update correctly from the background thread. You saved the day!

One easy approach is actually to take your idea one step futher – instead of making a TaskScheduler and passing it around, you can create a TaskFactory and pass it around:

TaskFactory uiFactory = new TaskFactory(TaskScheduler.FromCurrentSynchronizationContext());

Then, in your background thread, updating a UI item becomes:

string newText = ComputeText(); // Running in background thread/task
uiFactory.StartNew(() => this.textBox1.Text = newText);

It’s the same idea, but a bit less typing…

-Reed

Thanks for this posting. I needed an easy way to update the user thread in a GUI application when the task finished and this works like a treat. What I did need to do however is change the declaration of the context to

TaskScheduler context = TaskScheduler.FromCurrentSynchronizationContext();

and then pass the context to the task itself as a parameter.

If there is a simple way to update a control on the GUI thread without stopping the GUI thread then I would appreciate an uncomplicated example (like in updating a marqueeControl). I must be missing something because with the ‘old’ background threading scenario you just created an event.

Unfortunately, the Task class requires .NET 4. There is a back-port you can use that’s included with the Reactive Extensions framework. Installing that will allow the TPL to work on .NET 3.5sp1. You can download it here: http://msdn.microsoft.com/en-us/data/gg577610

I couldn’t agree more – especially your last sentence. I often find that performance and readability go hand in hand. Even if readable code performs horribly, it’s the easiest code to profile and correct, so it’s often a better starting point for all reasons, including focusing on perf.

-Reed

Optimization is overseen until it becomes a serious problem. Most developers dont worry about it, and patterns, processes and methodologies seems to do the same. I’ve been working with optimization over the last year, and found code blocks that are very beautiful, higlhy reusable and a nighthmare when considering the performance.

A few times, I have seen the opposite: ugly code blocks that where non reusable but working like a swiss watch.

The funny part is the fact that performance and readability or reusability are not opposites… Those situations only revealed the fact that developers have its own preferences, and it`s hard to find a developer that is focused in all those aspects.

Interessante post sull…