| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Comments:
<0> bah, i have to teach a stupid freshman CS lab tomorrow
<0> it's the 6th week of the course, and they're already up to functions with p***-by-reference parameters, omgwtfbbq!
<1> teach a lab? usually that seems to consist of sitting on ones *** and being annoyed every other second.
<0> twkm: exactly! especially by what i refer to as "one guy"
<2> Vratha, oh, there's always "this one guy".
<1> heh
<0> one guy is a math education major that is taking linear algebra for the second time this fall and is having on HELL of a time in this lab... and he plans to get into the graduate math program......
<0> KidArt: heh, yeah
<0> i was thinking, "linear algebra? two times? dude, just stop doing math education or you'll screw up some kids"
<0> the most impressive thing about him, computer illiteracy aside, is that he was asking some questions about basic modulo mathematics the other day
<3> that's pretty scary
<0> heh, yeah
<3> inability to grasp linear algebra doesn't bode well for his future as a math teacher
<3> unless he's teaching grade school or something
<0> sirBarfsA: i agree... i have no idea what he wants to teach (if he wants to teach), b/c he plans to get into a graduate program somewhere
<0> but, to be fair to the cl***, it's only that guy that annoys me... pretty much all the other students are quite good at figuring things out for themselves
<0> by the time most of them ask me a question, they've already done a lot of personal thinking
<4> haha
<5> Vratha, looks as if one is going to fail
<0> jeffloc: yeah :-/ i was amazed when he didn't drop by the drop deadline a week or so ago.. he was already just below 60% then
<5> the power of the bribe
<6> hrrrrm
<5> maybe
<6> locking problems are fun.
<0> oh well, such is life
<6> Vratha, other peoples lives, aparently.
<0> hehe
<0> Gambit-: are they starving?
<6> i'm trying to figure out a reasonable solution for acquiring N resources without starvation.
<5> philosophers deserve to starve!
<0> haha
<6> temporally sensitive as well.
<6> or chronologically sensitive, I'm not sure which is appropriate.
<0> Gambit-: multicast messages!
<6> Vratha, well in a sense, using conditions, something like that.
<0> have on philosopher go, "hey, this **** is mine until i'm done... you all starve until i'm finished!"
<0> yeah
<0> and if there are resources left, more philosophers can get in line to get resources
<0> probably just what you're doing
<6> hmm well it's discrete unique resources
<6> basically a bunch of objects in a system and threads would like to reserve 1-N objects
<6> heavily biased towards 1-2 mind you.
<0> maybe a mediator of some sort could handle the situation
<6> I'm thinking of a priority queue where each thread registers it's order and the objects it's interested in, and as a thread releases a resource it goes up the chain to the first object it finds looking for that resource and checks to see if all the resources it's looking for are available.
<6> if not, it blocks, otherwise it signals the threads to continue.
<0> like the line where they all line up and say "i want 1-N resources" and see if he can get them or not... at least one person will be able to get their resources all the time, so no deadlock should occur
<6> s/threads/thread/
<6> right, but in that case starvation will occur.
<6> because if someone says I want all N resources, that will never happen.
<0> hmm.. well maybe have them all ask for resources and then have the mediator make the best choices to minimize starvation?
<6> alternately I can say "as long as you've been waiting for under 50ms we'll let you wait a little longer if someone else wants to go"
<6> that's basically what I'm saying
<0> ah, ok
<0> sounds pretty good
<0> threads and conditions get pretty hairy though, i personally probably would've done it a little more concretely with some sort of mediator object... at least i think... though it might actually be easier with conditions like you're using
<6> a priority queue, check the delay and the interest, and if the interest matches and all the resources the thread are interested in are available, fire it off. If the interest matches but not all resources are available, and it's been waiting a short time, keep going down the queue, otherwise stop.
<0> but i was just commenting
<6> well what would a mediator object do differently?
<0> technically nothing, i just think it would be easier to debug should problems occur
<6> oh sure, it'll all be compartmentalized.
<0> ah, sounds great :)
<0> i'm sure you have a good handle on the problem as it is :)
<0> you seem too anyway
<6> *dryly* I hope so. I keep sorta hoping that there'll be a 'one true solution' one of these days, but it's too complicated a problem, unlike a list or something.
<0> i really doubt it.. is this for some OS course?
<0> heh, i'm not new, but i'm just wondering if you're doing it for a course or for work
<6> work, of course. I haven't been in school as a student in years :)
<0> ah, ok :)
<0> i think an approximation to the true solution is probably good enough; i imagine that a mediator that could get the best solution quickly would be a solver of all things NP ;p
<0> but it might not be NP-complete if i think about it hard enough
<5> exactly what are you trying to do. I seem to have joined in the middle of things yet again? you have made me curious
<7> Gambit: always acquire resources in the same order
<7> acquiring resources in different order = deadlock
<6> AndroMish, I'm dodging that issue by always acquiring resources synchronously, or not at all.
<5> sounds like the hard way
<0> nah, it's not too hard
<0> it's just a deadlock prevention algorithm it sounds like he's doing when he words it that way
<7> Gambit: is it database somethig ?
<5> there aren't different prioritys involved too?
<0> jeffloc: don't know
<5> that could make it very messy
<6> AndroMish, No, basically this mud I'm working on. There are different jobs coming in that deal with 1-N objects at a time, I need a way to acquire the necessary locks from other threads without deadlocking or starving people.
<6> plus, while I have a little chronological flexibility, I don't have a lot, so I sometimes have to block on an event until it gets serviced.
<7> Gambit-: the nice solution to multiple locks in refcounting
<7> the beauty of refcounting (vs locks) is, you can take them in any order
<0> Gambit-: what about not using strict ordering of events and instead using a weaker form such as versioning or something?
<7> s/in/is/
<6> Vratha, because things in a mud tend to be fairly chronological.
<6> AndroMish, I'm not sure how refcounting would really do what I'm talking about here.
<0> oh, well maybe a multicast group would be reasonable :-/
<5> that's because we aren't clear on just what you are doing.
<0> though, it sounds like you're doing pretty much that with the mediator
<7> I noticed that ppl start writing complex asynch things using locks, later switch to refcounting
<7> Including myself
<5> why do you need to lock them?
<7> It hurts if you don't have ready library for refcounting in place
<7> it's small amount of code, but it takes several days to polish it
<5> or rather do you really need to do it that way
<7> Or several hours, at least
<6> heh
<6> well let me summarize.
<6> No, that'd take too long, let me abstract:
<0> jeffloc: i can only ***ume it's so that when he updates one person, everyone else sees the same view of that person immediately.... though i think eventual consistency would resolve that issue via version numbers on objects
<7> yeah, change number is another technique
<7> i use it very rarely
<5> wait a bit. he's going to try to explain in less than 100 pages
<5> :)
<0> yeah.. references would probably make more sense, AndroMish
<6> Mud. Many objects. Jobs are temporarily sensitive. Jobs get queued to threads. Each job may require locking 1->N objects, heavily biased to 1 or 2 objects. Need to preserve locking without starving or getting jobs too desynchronized.
<7> Gambit: you need locking here, not refcounting
<6> Yup
<7> Gambit: have a function LockN and UnlockN that locks list/array of objects
<7> have this function sort objects by addresses, and lock in the order of addresses
<7> this will ensure that objects are locked in same order,
<7> thus avoid deadlocks
<7> LockN(num,list_of_objects)
<6> hum interesting idea
<7> alternatively, you can sort them by some ObjID for locking
<7> but you need consistent locking order among all threads
<7> this is the key
<6> sorting is trivial because N is a small number.
<5> is this a turn based thing or are you trying to make it real time?
<0> what happens in the case where one thread wishes to lock N objects? Gambit- mentioned he wanted to avoid starvation... i think he had the deadlock issue under control, based on what he said
<7> once you write these LockN/UnlockN functions, the rest is trivial
<6> jeffloc, basically a realtime thing.
<6> AndroMish, Right, I like it, I hadn't thought of that approach.
<7> starvation is more difficult thing than deadlocks
<7> it has to do with prioritization
<0> yeah
<7> even linux kernel sometimes does it wrong
<7> don't expoect it to be easy
<0> yeah
<6> Right, if the mutex prioritizes on FIFO then the thread locking N will walk it's way across the world.
<7> the right solution to starvation is to have CPU 90% free :-)
<7> if CPU is >50% loaded, there is no "right" solution
<5> too bad if his mud has 3000 users :)
<7> somebody will suffer anyway
<0> i think a scheduler would be pretty useful there... similar to the mediator idea i was talking about, except that is more on the point of what it should be doing rather than what i had more abstractedly said about it earlier
<6> jeffloc, if the mud has that many users it will be spread out across multiple physical machines anyways.
<6> Vratha, bandying terms about doesn't help if you don't have specifics :)
<7> i think linux scheduler is not perfect until now
<6> AndroMish, the nice thing about the approach I was thinking of is that it doesn't require a mutex per object.
<0> Gambit-: yah, well earlier i wasn't even thinking in terms of a scheduler :) so i didn't think to use that term :)
<7> although ingo molnar claimed great improvements in 2.6
<7> Gambit: which approach ?
<6> AndroMish, basically having a seperated bitmap protected by a mutex that indicated whether or not a thread was interested in a particular object while it waited in the priority queue.
<7> hmmm
<7> bitmap per thread ?
Return to
#c
or
Go to some related
logs:
#online
BitchX-Baby
.diz winrar overwrite
#computers
#solaris
Pivotal pools
#politics
#fedora
OXYGEN3COM
#nhl
|
|