Frank Bakker - All Comments

re: Visualizing Linq operators: The Info Support Linq Posters

frankb — Fri, 19 Mar 2010 13:13:15 GMT

Following up on the requests above we now have both posters available for download from our website.

www.infosupport.com/linq

re: Visualizing Linq operators: The Info Support Linq Posters

frankb — Wed, 10 Mar 2010 11:08:07 GMT

Hi Daniel,

I'll check your request for the download with our guys at marketing, unfortunately I'm only responsible for the content', not the distribution of these posters

re: Visualizing Linq operators: The Info Support Linq Posters

Daniel Wolf — Wed, 10 Mar 2010 08:05:24 GMT

Any chance of getting the second poster as a download, too?

We thirty developers, but I can't reasonably ask you to send us that many prints. Plus, the Dutch form is kind of a problem. For the life of me, I could not figure out what the mandatory field "Voorletter(s)" meant - I ended up simply re-typing my name. Apparently, that was not correct, as I haven't received an answer since.

re: CacheDictionary for .Net 3.5, using ReaderWriterLockSlim ?

frankb — Tue, 09 Mar 2010 11:51:15 GMT

Hi Tamus, thanks for your comments.

Did you by any chance do any perfromce testing to compare the ReaderWriterLockSlim to an exclusive Mutex / Lock?

The point of my post (and Joe's) is that ReaderWriterLocks are in reality slower then mutexes in most scenario's. The only exception beeing when readlocks are held for a relative long time.

re: CacheDictionary for .Net 3.5, using ReaderWriterLockSlim ?

TamusJRoyce — Mon, 08 Mar 2010 18:21:54 GMT

I have a similar setup using an IBindingListView here at work using the ReaderWriterLockSlim. But instead of making a single thread-safe method not found on the class, I have made every implemented interface of IBindingListView thread safe.

I had to make the ReaderWriterLockSlim allow recursion via the constructor, but it seems to work very well.

I use [Enter/Exit]UpgradeableReadLock() for reading, and [Enter/Exit]WriteLock() for writing. I also have an IEnumerable/IDisposable object that holds a reference to the collection and calls the collections ReadLocking/Unlocking automatically, making For Each calls thread safe.

And what about Modification while Enumeration? Simple. I use regular locking on a separate List(Of T) in which caches items being added/inserted until all ReadLocks & WriteLocks are dissolved. Then I simply get a write lock, and write that back to the collection.

If it wasn't that it was written at work/licensing, I would gladly open source it, so it could be applied to Dictionaries, tables, rows, etc...

It is quite a bit more complicated, but it is possible to have a fully thread safe collection that automatically performs thread safety for you.

With the combination of PFX, this could add a new layer of intuitiveness to this powerful framework...

re: Visualizing Linq operators: The Info Support Linq Posters

frankb — Tue, 19 Jan 2010 07:49:35 GMT

Hi Francis,

The Irst poster (the one on the right) is only available in print, we will sent it to you free of charge if you fill in the form on the website. The second one (on the left side) is available for download in pdf.

re: Visualizing Linq operators: The Info Support Linq Posters

Francis Dallaire — Mon, 18 Jan 2010 20:13:03 GMT

Is it just me or there's only the first part of the poster on the website ? Thanks

re: New coordination datastructures in .Net 4.0 Beta 2

frankb — Tue, 12 Jan 2010 07:56:44 GMT

Hi Hero, thanks for your commens

What I did not describe in tis or any of my previous posts on this subject is the usage pattern for this style of cache. This might be a tipic for a next post.

In the way I use this cache, I actually do use an inline delegate for the producer that captures the key and potentially any other required variables from the surrounding scope to create the new value. This should not be a problem, because the cachekey is also used as the index in the underlying ConcurrentDictionary, so each different key will have a different instance of Lazy<T>.

The new GetOrAdd operation on ConcurentDictionary does solve this problem by providing the key to the producer delegate. You could just use ConcurrentDictionary directly without the need for my CacheDictionary at all. The only thing you do net get from ConcurrentDictionary.GetOrAdd() is the guarantee thet the producer will be executed exectly once, depending on your scenario that might or might not be a problem.

re: New coordination datastructures in .Net 4.0 Beta 2

horo — Mon, 11 Jan 2010 12:35:48 GMT

Hi Frank,

Thx for the idea of using Lazy<T> with ConcurrentDictionary.

However this implementation CacheDictionary leaves an unresolved problem open: producer() needs to know the "key" to create its return value. Unfortunatelly Lazy<T> does not provide a standard way to pass parameters to producer().

Using any inline implementation for producer(), and referencing the "key" local variable of Fetch method of course not a solution, because the return cacheItem.Value; statement potentiali can run in an other thread, with other actual "key" parameter than the thread which added the cacheItem to the dictionary.

New coordination datastructures in .Net 4.0 Beta 2

Frank Bakker — Thu, 12 Nov 2009 08:54:41 GMT

To be honest a have not spent too much time looking at .Net 4.0 beta 2 yet. But I do keep up with the

re: Visualizing Linq operators: The Info Support Linq Posters

Buck Thompson — Mon, 24 Aug 2009 12:15:03 GMT

I was just thinking about sticker and you’ve really helped out. Thanks!

re: SQL Server 2005 vs. Office Web Components

peezy — Tue, 18 Aug 2009 15:28:50 GMT

I agree!

Manually installing the OWC11 was a lot easier!!!

Thanks MikeP...

P.S. As mentioned earlier, I would not be able to do my job w/out blogs....

re: CacheDictionary for .Net 3.5, using ReaderWriterLockSlim ?

frankb — Tue, 04 Aug 2009 11:26:04 GMT

The confusion comes from the way LazyInit<T> (or Lazy<T>) works. The constructor retrieves the delegate (producer) but does not invoke this delegate yet.

The delegate is only invoked the first time the Value propertiy is retrieved which is done outside the lock()

re: CacheDictionary for .Net 3.5, using ReaderWriterLockSlim ?

Mike — Mon, 03 Aug 2009 20:35:44 GMT

Disregard, I see it now.

re: CacheDictionary for .Net 3.5, using ReaderWriterLockSlim ?

Mike — Mon, 03 Aug 2009 20:32:21 GMT

You will deadlock if one of the thread 'producer's infinitely blocks on line 14 in the last example.