Wednesday, March 14, 2007

So I had a breakthrough last night...

I spend most of my free time on the computer doing homework (free time defined as not at work, not spending quality time with family).

Anyway, this will be less than interesting to you, but I got so excited I had to share. I had a breakthrough last night--I'm not going to get nominated for a Nobel prize anytime soon because of it, but I was excited since this has been vexing me for days.

I'm writing a program that simulates a barber shop. Why a barber shop? Because it demonstrates some basic computer operating system concepts (Windows, Mac OS, Linux, and all the others all have to deal with this particular issue). The problem is that there is only one barber and he can only serve one person at a time. If the barber has several people come in at roughly the same time there has to be a mechanism to control who gets to sit down in the chair.

In a computer system the barber is a shared resource, usually thought of as a piece of data that resides on the system, but could be any other system resource. The customers are programs that need to use the piece of data--the task is to write an underlying operating system (like Windows) in order to match the needs of the customers to the availability of the barber. It’s both complicated and simple at the same time.

Basically what you have to do is have the customer look to see if the barber is already busy--if he is the customer sits in the waiting room and waits until the barber is free. If he's free the customer sits down and gets a haircut. Oversimplified of course, but that's the general concept.

Where my breakthrough came in though was in the timing of it all. Forcing pauses (each haircut is supposed to take a random time between 1 and 3 seconds and customers come in at random intervals, between 1 and 3 seconds), keeping the barber busy, and making sure the waiting room doesn't get overcrowded, are all very manageable actually. But how to continuously generate customers over a two minute period? Ah, that's what has been plaguing me for days. Now that I've solved it, the solution looks obvious.

I was trying to figure out how to make my program to run for two minutes and then stop, while continuously generating new "customers" every 1 to 3 seconds. I was using a for-loop, nested inside either a do- or while-loop, but I couldn't figure out why it was ignoring the do and while loops and only exiting when the for-loop completed. It also wasn't very elegant since I had to predefine an upper limit for the for-loop.

My first solution looked like the following. One other note is that the method call to System.currentTimeMillis() gives the time since January 1, 1970 in milliseconds (a very, very huge number)--120,000 milliseconds is two minutes. So basically, it is supposed to finish when the start time equals the current time minus two minutes (clever, actually--well, I think so anyway). Anyway, here's the code I tried first:

long startTime = System.currentTimeMillis();

while (startTime >= (System.currentTimeMillis() – 120000) ) {

for (int customerID = 1; customerID < 100 ; customerID++) {

threadWait();

customerID++;

}

}

It seemed like it would work, but runtime would take over three minutes and it wouldn't stop until customerID equaled 100! I know, right? Annoying.

Finally, late last night, around 12:30 AM, I realized that there is a much easier (and like I said, obvious) solution. Junk the for-loop since I don't really want to have a limit on the number of customers in the two minutes anyway. Reality is that I wouldn't approach one hundred in two minutes, but once the JVM enters a for-loop I guess it ignores whatever other instructions there might be. And voila! It becomes a simple do-loop that increases the customerID each time it generates a new customer.

long startTime = System.currentTimeMillis();

int customerID= 1;

do {

new customer(customerID);

threadWait();

customerID++;

} while (startTime >= (System.currentTimeMillis() -120000));

Like I said, this will be less than interesting for most folks, so if you've read this far then you have my congratulations. But, if you've read this far AND you've understood everything then we need to talk because I might have some questions for you... :)

9 comments:

Deb Ellsworth said...

so I read the whole thing but the reality is that you lost me here: "Where my breakthrough came in though was in the timing of it all." After that I fell asleep... :) But way to go, sounds like you figured something out.

Stefanie said...

huh?

David S. said...

And if I had written: Silver on a bay creates a "red silver" or a "silver bay". The horse will have a red body (as red is undiluted), and a flaxen mane and chocolate-colored legs. It will look like a bay with a flaxen mane and tail-- and if you look close, you'll see the legs are not black, but a diluted sepia/chocolate color.

Silver on a chestnut doesn't show up; silver can't dilute red pigment. Many horses are mistakenly called "silver chestnuts" because they have the flaxen gene, which creates a flaxen mane and legs on a chestnut/sorrel horse. This is not silver . This is only flaxen.

--would you have understood? :)

Stefanie said...

of course! that made perfect sense :)

Deb Ellsworth said...

huh?

David S. said...

Ok, Deb, this one's for you:

The arcane tree gives "utility" talents, such as passive increases and bonuses to mana, silences added to spells, and increased armor. At higher levels, the arcane tree offers powerful spells designed to maximize the mage's damage potential, which gives the mage class the highest burst damage in the game (with appropriate gear). To balance this raw power, the spells have “cooldowns” during which the mage cannot use them. The fire tree focuses on fire spells, which increases the raw damage and enhances the utility of their spells, offering very powerful area-of-effect spells. Combat usually focuses on unloading a host of high-damage critical strikes in a short amount of time, usually giving the opponent no chance to react. The frost tree offers more control in the form of slowing and freezing opponents, and offers better survivability due to ice shields and elemental minions. Nonetheless, the frost tree can deal out a fair amount of damage when a fight is “controlled” by the mage. It does not rely on cooldowns like the arcane tree, or “initial” control of the fight, as in fire. Rather, frost has a slightly lower burst damage potential.

Deb Ellsworth said...

LOL!!! My mage was fire but I just recently changed her to frost.

That was SO funny...

Suzanne Earley said...

lol.

i don't even want to try to understand you guys.

you scare me.

lol

David S. said...

This thread (!) was from April, but I realized I had left someone out...

The crosswise threads, or grain, have a small amount of give to them; they will stretch a little. The lengthwise threads will not stretch at all. Cutting the fabric at a 45-degree angle to the crosswise and lengthwise threads produces a bias edge, which stretches a great deal when pulled.

Pay careful attention to the grain lines marked with arrows on the templates given with patterns, when marked. These arrows indicate that the piece should be placed on the lengthwise grain with the arrow running on one thread. Although it is not necessary to examine the fabric and find an exact thread to match, it is important to try to place the arrow with the lengthwise grain of the fabric.

Bias strips are used if stretch is needed, such as for binding curved edges, stems for flowers or some appliqué shapes.