几道英文面试题

1. What factors would you take into consideration when choosing a data structure and algorithm for a dynamic lookup table?

2. Under what circumstances would busy waiting be acceptable in an interrupt handler?

3. What would the following C print out?
＃i nclude <stdio.h>
int main(int argc, char *argv[])
{
 int x = 1;
 printf("%d %d %d/n", ++x, x, x++);
 return 0;
}

老外的回复：第一题


In <lAOKe.87031$G8.37102@text.news.blueyonder.co.uk> "jimjim" <netuser@blueyonder.co.uk> writes:

> Hello,

> What factors should I take into consideration when choosing a data structure
> and algorithm for a dynamic lookup table? Any pointers, pitfalls and
> thoughts please?

Key size
Relative frequency of lookups, inserts, deletes
Desired performance for lookups, inserts, deletes
Frequency of collisions
Data storage format (binary file, XML file, ??)



--
John Gordon "It's certainly uncontaminated by cheese."
gordon@panix.com

David Schwartz

2005-08-11, 5:03 pm
    
"John Gordon" <gordon@panix.com> wrote in message
news:ddge0k$8fv$1@reader2.panix.com...

> In <lAOKe.87031$G8.37102@text.news.blueyonder.co.uk> "jimjim"
> <netuser@blueyonder.co.uk> writes:

[color=darkred]
[color=darkred]
> Key size
> Relative frequency of lookups, inserts, deletes
> Desired performance for lookups, inserts, deletes
> Frequency of collisions
> Data storage format (binary file, XML file, ??)

Also:

Relative importance of performance versus resource consumption.
Relative frequency of different types of lookups, if applicable.

It basically comes down to these questions:

1) What kind of data am I storing?

2) What kind of operations will I be performing on it and how often?

3) What am I trying to get out of this data structure? (Performance?
Ease of implementation? Maintainability? Low memory consumption? Minimal
disk access?)

There is no substitute for experience and keeping current with the
literature. 9 times out of 10, whatever data storage problem I'm dealing
with, someone spent 5 years studying it and came up with a solution that is
better than the one I could come up with in the time available (rarely 5
years).

If you don't know at least one of Lawson, Jenkins, or Matsumoto and
Kurita, you aren't a good programmer. They developed extremely good hash
sizing functions, hash value functions, and pseudo-random number generators
respectively.

DS

第二题：

On Mon, 15 Aug 2005, jimjim wrote:

> Hello all,
>
> Under what circumstances would busy waiting be acceptable in an interrupt
> handler?

Not many: only when the thread that's blocking you is running on
a CPU would be the main (if only) circumstance. I'm no expert
in such things, alas, but what prevents you from using an adaptive
mutex?



--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
jimjim

2005-08-15, 5:02 pm
    >> Under what circumstances would busy waiting be acceptable in an interrupt
>
Is an interrupt handler essentially a function that handles the reception of
some signal type? What may an interrupt be other than a signal?

> Not many: only when the thread that's blocking you is running on
> a CPU would be the main (if only) circumstance.
>
I cannot understand your point.




Rich Teer

2005-08-15, 5:02 pm
    On Mon, 15 Aug 2005, jimjim wrote:

> Is an interrupt handler essentially a function that handles the reception of
> some signal type? What may an interrupt be other than a signal?

Ah. Are you talking about a signal handler in a process, or a
kernel-resident interrupt handler? The two are very different
beasts! (I was assuming the latter.)

> I cannot understand your point.

If you spin waiting for a resource that is currently held by some
other thread, and that thread isn't currently running, you could
potentially spin for a long time waiting for that resource to become
available (which of course wastes CPU cycles). Going to sleep waiting
for the resource is the better solution in this case.

OTOH, if the holding thread IS currently running on a CPU, it's reasonable
to assume that the resource you're after will become free fairly "soon".



--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
David Schwartz

2005-08-15, 5:02 pm
    
"jimjim" <netuser@blueyonder.co.uk> wrote in message
news:YH2Me.89397$G8.73658@text.news.blueyonder.co.uk...

[color=darkred]
> Is an interrupt handler essentially a function that handles the reception
> of some signal type? What may an interrupt be other than a signal?

No, interrupt handlers have nothing to do with signal handlers. Signal
handlers handle signals. Interrupt handlers handle interrupts. Signals
signal a process. Interrupt handlers interrupt a processor (to handle some
highly-important task immediately).

[color=darkred]
> I cannot understand your point.

Say you have two network cards that are using the same driver. An
interrupt for card A is running on CPU 1. Then an interrupt for card B
starts to run on CPU 2, but it can't get the lock it needs. It is usually
acceptable to wait for the interrupt handler on CPU 1 to release the lock.
Needless to say, interrupt handlers don't hold locks for very long, ideally
just a few dozen instructions. The cost of yielding would be higher than the
cost of spinning.

DS




Maxim Yegorushkin

2005-08-16, 5:05 pm
    
jimjim wrote:
> Hello all,
>
> Under what circumstances would busy waiting be acceptable in an interrupt
> handler?

Only if there are multiple processors you need to disable interrupts
and use spin locks. For a uniprocessor disabling interrupts is enough.
This is done transparently to you using spin_lock_irq() macro from
linux/spinlock.h

Also note, that in Linux interrupt handling is serialized, that means
it's guarantied that only one thread will execute you handler at time,
the handler does not need to be reentrable. do_IRQ() function does this
serialization.

junky_fellow@yahoo.co.in

2005-08-16, 5:05 pm
    
Rich Teer wrote:
> On Mon, 15 Aug 2005, jimjim wrote:
>
>
> Ah. Are you talking about a signal handler in a process, or a
> kernel-resident interrupt handler? The two are very different
> beasts! (I was assuming the latter.)
>
>
> If you spin waiting for a resource that is currently held by some
> other thread, and that thread isn't currently running, you could
> potentially spin for a long time waiting for that resource to become
> available (which of course wastes CPU cycles). Going to sleep waiting
> for the resource is the better solution in this case.

A thread should not call sleep while holding the spin lock. It should
always
release the spin lock before going to sleep. An ISR should never call
sleep
because this in turn will deschedule the process that was running when
the
interrupt was received. An ISR may take a spin lock while accessing a
global
variable but other thread should never hold that lock for a long time.
The kernel may have some timeout mechanisms that ensure that if the
ISR/thread
fails to get the spin lock with in a specified time, the system would
panic.