Re: What Impact Do Static HashTables and Classes have on the CPU?

On Mar 28, 8:17 am, "Mark S." <m...@xxxxxxxxx> wrote:
Every request makes decisions based on what the other request had written to
the static hashTable and then writes what it decided to do back. This
sequential decision makes is required by the code's business logic. If you
or anyone else has a better way to achieve this logic, I'm open to
suggestions.

OK... I'll take a crack at it.

First, though:

1. What are the keys in the hash table? What do they represent?
2. How many keys can there be?
3. How are they structured?
4. How (and when) can new keys be created?

Once I know the answers to these questions, perhaps I can suggest a
better structure.

A preview... what I'm thinking now.

The problem with a hashtable is that the correspondence between a key
and the corresponding hash bucket and its chain of keys is arbitrary.
This means that two threads writing to the same hashtable practically
have to lock the whole structure and therefore run serially.

If, however, you could create a different structure that understands
the structure of your keys, you might be able to selectively lock only
parts of the structure. Viz: one thread writing to the structure under
key A might be able to run in parallel with another thread writing
under key B if the two keys have nothing in common within the data
structure. If you were, for example, to roll your own hash table, you
could attach a different lock object to each hash bucket, and lock the
buckets individually rather than taking out a lock on the entire
table.

Of course, whether this gives you improvements in concurrency entirely
depends upon the nature of your problem. If it is highly likely that
all threads will be working on the same key at the same time then it
doesn't buy you much. If, on the other hand, multiple threads are
likely working on different keys at the same time, and the keys can be
structured so that they are unlikely to land in the same part of the
collection structure, then it's highly likely that threads will run
without any locking contention whatsoever.

As usual, the answer is, "It depends." It depends upon the answers to
those questions, above.

.

Relevant Pages

  • Re: Still Struggling...
    ... I still think the relationship is between keys and locks, ... Ignoring master keys for the moment, you have One Lock: Many Keys, so LockID is a FK in tblKeys. ... One master key can open several locks, and each lock can be opened by several different keys including the master key. ... If there is to be a junction table I think it would be between locks and keys. ...
    (microsoft.public.access.gettingstarted)
  • Re: Still Struggling...
    ... I don't think it would be a junction table. ... lock is an entity with certain characteristics such as brand, location, date ... One Lock can have many keys. ... Similarly, one lock may have many keys, but other than master keys a key may open only one lock. ...
    (microsoft.public.access.gettingstarted)
  • Re: Still Struggling...
    ... KeyID (1/2 PK, FK to tblKeys, number, l.i.) ... tblLocationTypes 1:M tblLocations ... It would be nice to have a list of unassigned keys but...it's a little ... One Lock can have many keys. ...
    (microsoft.public.access.gettingstarted)
  • Re: Still Struggling...
    ... While keys are what drove my desire to create this db in the first place, ... but once we changed tblRooms to tblLocations, ... One Lock can have many keys. ... If it was me I think I would have an AssignedTo ...
    (microsoft.public.access.gettingstarted)
  • Re: Hey, stop picking that lock!
    ... Dungeon skeleton keys aren't a "back door" by any stretch - they lie ... But shopkeepers would have to leave their shops unprotected while ... combination lock or a magic-only lock on everything they could. ...
    (rec.games.roguelike.nethack)