| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Comments:
<0> bitmap per thread ?
<1> locking and unlocking are heavierweight, for sure
<0> are your locks someting in the database, or just mutexes ?
<2> what if you gave each object a strict time limit on how long it could hold an object? not necessarily in terms of real time, but maybe in terms of instructions that can be performed on it plus a max delay between doing each instruction or something?
<2> s/object/thread/
<0> Gambit looks up to ears in the mud
<2> that way the threads have to meet deadlines or risk losing access to the objects for that round?
<2> just an idea... maybe it won't be for you
<1> Vratha, I'll be doing something like that as part of hardening the scripting language against poorly formed scripst.
<1> AndroMish, just generic problems, tbh. Getting back in the groove of thinking about these things :)
<1> What do you mean by the lock being something in the database?
<0> you said it's multicomputer
<0> if two threads run of different comp and want to lock same object ...
<2> Gambit-: do the clients (i ***ume you have clients of some sort) have direct access to the objects? if not (and i don't think they should), why don't you just have clients send messages to the server and let the main server thread handle everything with message ordering and all that? or maybe even a group of servers
<3> that'll make his locking fun
<0> then you want to put locks into database, no ?
<2> i just think that would simplify things a lot... i bet you might be able to get rid of all sorts of separate threads
<3> Vratha, I was going to say something similar
<1> I was thinking originally that each object would be hashed to a position on a bitmap. As an entry is released, a central mutex is taken and the list of waiting threads is iterated through to see if anyone's bitmap matches the one being freed (or rather, the bitmap of free objects). If it does, that thread is signaled to try to acquire the locks it's looking for, otherwise it continues on until it finds one that does match.
<2> jeffloc: :-D jinx! owe me a coke
<1> Vratha, because the main server is more then one thread, of course.
<3> just queue up the messages and run through them one at a time. first in gets it
<2> alright; i guess i just don't understand why it needs to be more than a few threads
<1> AndroMish, Right, there'd be locational segregation to keep that from happening.
<1> Vratha, it doesn't, but given todays multi-core systems, it makes sense to make use of them as much as possible.
<3> I have done similar games (not large ones) in the past and I always queued up requests
<2> Gambit-: oh, yes, i definitely think you should optimize for the hardware... i just thought you had multiple threads for the heck of it
<1> I'm only thinking 5-10 threads under normal cercumstances.
<3> it worked fine
<1> Vratha, I don't do things for the heck of it :)
<1> jeffloc, well there will definitely be queues involved here.
<2> hmm
<3> but do you really need multiple threads for the part that processes the users requests
<1> AndroMish, or if not locational, at least contextual of some kind.
<1> jeffloc, who said anything about this being the part that processes the users requests?
<1> this is the worker thread pool I'm talking about.
<3> I used a thread for each connection to users but they all queued up for one process to handle the work
<1> jeffloc, Yuck!
<3> why yuck ?
<1> jeffloc, I have exactly the opposite configuration :)
<1> because a thread for each connection is a waste of resources.
<2> Gambit-: well, there are a few types of scheduling algorithms to schedule jobs across multiple CPUs (or cores in this case).. had you thought about any of the typical ones like gang scheduling or.... umm, can't remember names... the one that has a dedicated scheduler on one CPU, or anything like that?
<3> not really
<1> Vratha, scheduling isn't my problem, I just let the OS take care of that. Resource contention is more of my concern.
<1> jeffloc, sure it is. Why do that when you can asyncio and have one thread do all the work?
<3> you have been complaining about the reason
<2> Gambit-: well, i mean maybe you could have one thread that just handles telling which threads can go to work now, reducing starvation... i guess this goes all the way back to square one where i thought you should have some sort of "mediator" (i.e. scheduler) to schedule jobs, based on minimized starvation and other factors you consider for fairness
<3> I hate making things more complicated than they have to be
<1> Vratha, yeah, but why have a seperate thread to do that? It'll only come up when a resource is released or requested, so the existing thread might as well do the analysis there instead of paying for a context shift.
<2> Gambit-: ok, well you can do that i guess, as long as the data is consistent amongst all the CPUs
<1> calc c10k
<4> Ten thousand clients simultaneously -- an analysis of the problem: http://www.kegel.com/c10k.html
<1> Vratha, doing mutex locks causes data synchronization, which is painful.
<2> ok
<1> it's something I'd like to get around if possible, but I'm not sure I can do it and still stay multithreaded.
<1> which raises the question of multithreading in general.
<2> your data could stay in sync if you tie objects to certain CPUs
<2> that way no data sharing would have to occur amongst the CPUs
<2> maybe that could simplify your decisions and let each CPU/core handle its own data
<2> but in those cases you have to share data, i think you're just stuck having to tell each CPU that new data exists via a mutex or something
<1> I think the sync happens at lower levels then you're talking about, but I haven't isolated the mechanism.
<2> oh, someone else's code you're expanding?
<2> well anyway, i appreciate the problem you're working on, but i gotta get going
<1> no, it happens in the OS or hardware if it happens at all.
<2> oh, right
<2> the hardware would be the one sync'ing the caches when the main memory is changed and the CPU uses it
<0> Gambit: i don't think the bnitmap is good idea; but I'm interested to hear if you fiond it is
<1> AndroMish, *nods* I'm not sold on it either, but I think I'll hash it into some pseudo code and run it up the pole.
<2> very simply, without mutexes, you could sync each CPUs cache with a simple write back to memory... but you'd have to protect writes in case of race conditions
<2> so i guess a mutex for write
<2> well whatever
<2> i'm getting tired
<2> just ignore what i said there
<2> good night :) good luck on the problem, Gambit- ; let me know how it turns out
<1> AndroMish, Oh, btw, the problem with the 'sort by number' problem is that it is not deadlock proof.
<5> Is there a standard semaphore library?
<6> nope.
<6> but many platforms have them.
<5> Its explicity platform dependent?
<6> i guess you could say that.
<6> in that there are no semaphores in the c standard.
<5> Is a lock/mutex/etc need to be explicit with a threaD?
<6> the c standard doesn't defined threading either.
<5> Hrmpf
<6> just because you use threads does not demand a mutex.
<6> what does need a mutex is accessing a object from multiple threads.
<5> twkm, I'm editing a data structure in one thread and reading it in another
<6> then you need a mutex, though perhaps you can afford something lock-free, but those are tied to hardware more than platform.
<5> how is a mutex not lock free?
<6> a mutex is itself a lock, you stall at the mutex if it is locked by another thread.
<0> JoelS: there's posix sema_ functions
<0> sem_
<0> sem_init etc
<6> provided we're talking posix and not something else.
<6> ditto sysv or posix semaphores, your thread stops if it is already locked.
<0> if posix, then sem_*. if wrapper of some sort, them ACE probably
<0> i hate ace though
<5> Hmmm... I obviously don't know enough here
<0> whyich OS are we talking JoeS ?
<6> does it matter if your thread stops to wait for the lock to clear?
<6> i.e., do you need lock-free?
<6> sometimes you prefer to lose an event that to stall, for those cases lock-free is ideal, though far less portable.
<5> I'm not sure at this point
<0> lock-free is so advanced topic
<6> but mostly people write code so that they can afford to stall, and they do not want to lose the event. for that you are better off using the platform supplied locking.
<7> illegal reference to non-static member 'Team::Name'
<7> i dont get it nothing has been static
<6> exactly. that is annoying the compiler, it should be static.
<6> well, should be for the way you are using it.
<6> might not be sane to make it static, rather you should change how you use it.
<0> wwhitay: are you using non-static member from a static function ?
<7> both were nonstatic, now i made them both static and it doesnt throw that error
<6> damn, no wonder people paste google and youtube links, there's so much ****e you get a boner when you find a pearl.
<0> got porn links, brother ?
<6> no.
<6> but i've managed to learn to avoid the zillion and one pvp pieces of ****.
<0> pvp ?
<8> Crappy videos from WoW
<6> video recorings of graphical games.
<6> yeah, mostly wow it seems.
<6> i thought i'd kill some boredom. all i got was more.
<9> http://youtube.com/watch?v=8hUnjFi08s8
<6> youtube are the worst; content is not much different, but the resolution and access is harder. but, let's see what http://youtube.com/get_video.php?video_id=8hUnjFi08s8 looks like.
<6> heh, and youtube seems to be running a litle slowly, lets see if mplayer has enough to work with yet.
<10> if you have a tcp server doin poll() how can you add another socket etc if its single threaded?
<6> ahh, yeah, that video.
<0> what does "pct verser doin llop" mean ?
<6> kthx^: increase the size of your array.
<10> no
<6> kthx^: put another element into it.
<10> like how can i add a socket if its a loop with poll?
<0> my best guess is, you can't
<6> before or after the call to poll, change it.
<10> while(1) { accept(); addpoll(); } ?
<0> cd /opt/linux
<0> ls
<0> oops
<6> do { poll(); ... { accept(); add(); } ... } while (42);
<10> 42?
<10> EH
<0> kthx^: do you live in AZ ?
<10> AZ?
<10> eh
<10> ...
<10> isnt poll() supposed to be in a loop and not return hence how can you add sockets etc?
<6> eh?
<6> do { you call poll. it tells you what to do, you do it. } FOREVER;
<0> kthx^: depends on the state
Return to
#c
or
Go to some related
logs:
#delphi
#politics
müziğim.1
altadreb
goalll cheaters
#visualbasic
t.d.debit green card
barnessf
#nhl
#beginner
|
|