Matt_D

Members
  • Content count

    180
  • Joined

  • Last visited

Community Reputation

247 Neutral

About Matt_D

  • Rank
    Member
  1. [quote name='Tanel' timestamp='1298989238' post='4780542'] Actually there is one static object that is being changed by several threads. And when its being changed it is being locked like this: lock(Object) { } And it might cause deadlocks. [/quote] yeah. dont do that. 90% of the time, you want to try as hard as you can to give threads [i] local storage [/i]. ie: their own copy of the data they need to work on. this is generally the paradigm for bulk processing (eg: create a copy of some data you need to process, pass the copy to the thread, thread works on the data, generates results. when [i] all [/i] threads are done, we commit the results over the top of the original data ). 10% of the time you actually need to share things. you should be spending most of your time trying to share (as in, needing write/read to a shared memory location, not having its own copy of data) as little as humanly possible between threads. sharing means that you [i] absolutely completely and utterly must [/i] ensure that you do not introduce race conditions. this means you either need to lock, or you need to use a lock free queue. so, first step. do you need to share this information? do [i] all [/i] of your threads need to be able to write and read from this buffer? (i would guess, no). secondly, if things absolutely utterly have to write and read from this a the same time, its time to have a read through the rather nice concurrency lock free primitives that are part of .NET. I suggest reading up on lock free in general before you even start this process. actually, I wholeheartedly recommend taking some time out to learn about syncronization primitives, about thread priorities and the problems that can cause, and also how to write effective thread layouts.
  2. [quote name='Tanel' timestamp='1298988014' post='4780536'] No i doubt this is about deadlocks, because mysql thread, login server thread and game server thread freeze at the same time. Anyways the login and game server use async sockets and are on non-blocking mode and the mysql uses pooled connections which are created each time a query is made. I don't run under debug mode, but when I did it used to freeze also, so i couldn't change absolutely anything in the sourcecode and yes, there are exception catchers everywhere. [/quote] im still betting that this is a deadlock (http://en.wikipedia.org/wiki/Deadlock) . Im also guessing that you are trying to write to a shared buffer somewhere, and everyone's waiting on everyone else for write access. thats why everything is freezing. the question is, what's shared between them all. are you using the .net concurrency lock free primitives? how are you locking and unlocking resources? what resources are shared? we need a lot more information!
  3. [ ill be nice, its your first post, but please provide lots of information! ] odds on, you have both threads waiting on the same semaphore. welcome to the fun world of deadlocks. what thread syncronisation primitives are you using? where do you sync your threads? how do you copy data about? are you using lockfree? do you know what you are doing with threads?
  4. ~ threads ~

    I would avoid heterogeneous thread layouts (that is, running a lot of different threads at the same time). what you want to do, is break your game loop into "steps" and "jobs". at each "step" and "job" you want to go as wide as possible. using your threads, as a constantly running thread pool. so, your game loop ends up like prephysics gameplay - prephysics AI - physics - post gameplay - post AI - generate render lists - async IO. and within each "step" there may be multiple "jobs" which get run, as "wide" as possible. so your physics step, may have a raycast resolve, an update, and a collision resolve. not all jobs will be able to go wide (eg: UI) but some jobs will be easier to multiprocess (async IO/physics). its pretty typical to run a separate render thread regardless, which is fed from the render list point in your game loop. you should also aim to keep each "step" as completely dependency free as possible. and only communicate between steps using events. in each job. use lockfree queues to write results from worker jobs to. also use "copies" of data for worker threads. and only commit all the updates when the job has finished. this ensures that you have consistent state during processing, and gives you consistent synchronisation points during execution. doing things this way, with a mostly homogenous thread layout, wins you massive instruction cache coherence, good predictability in terms of deadlock/livelock problems, very little actual mutex/other usage.
  5. MMO Architecture

    [quote name='rgibson11' timestamp='1298158485' post='4776479'] I am interested in developing a rather simple MMO game demo, [/quote] oh dear, here we go. such a thing does not exist. [quote] I have read about some rather complex MMO architectures involving governor servers and a bunch of confusing diagrams. [/quote] if the diagrams are confusing, that should be a good sign that you do not have the required experience to continue from this point. have you got 2 players on a server before? how about 64? or even 128? the login server will be used to place users on servers based on overall system load. if you dont plan on having many servers (and really, how much money are you willing to spend on hardware/network connection to support 5k players?) then you dont need to divide your population, and you can do everything in one place. for the record, 5k players is MO, not MMO.
  6. Enumerations in C++

    [quote name='Geometrian' timestamp='1296683558' post='4768727'] Hi, I'm porting over my fairly large scope Python graphics library to C++. I was wondering what the best way to go about defining flags would be. The behavior I'm looking for is:[code]flags = FLAG1 | FLAG 2 | FLAG 6; ... if (flags&FLAG1) /*something that will execute*/ if (flags&FLAG2) /*something that will execute*/ if (flags&FLAG3) /*something that will not execute*/ if (flags&FLAG4) /*something that will not execute*/ if (flags&FLAG5) /*something that will not execute*/ if (flags&FLAG6) /*something that will execute*/[/code]There are several hundred or so flags, and some functions can potentially take many combinations of many different flags. So that conflicts do not occur, currently, I have a flag class that treats any flag as a single 1024 bit number (implemented with several 64 bit numbers). This doesn't seem like the right solution to me. I was considering enums, but I do not know how many different flags they can take, and still maintain this behavior. What's the right thing to do in this situation? -G [/quote] to not do that at all rather than have one array with all your objects in (for example), have multiple arrays which store different data that needs to be processed differently. this has a few impacts a - you wont need a massive switch statement to work out what code to run on this object, you also wont be switching what function you actually use for each object. gaining both instruction cache coherence, and avoiding unnecessary branches b - you'll be able to avoid having a massive and unmaintainable list of bitflags to control what is essentially a type/id flag in your data basically, design your code around your data, not the other way around.
  7. C# vs C++

    [quote name='linux' timestamp='1296841358' post='4769611'] Hello everyone, How come XNA was made in C# not C++? Many people know that C++ is much stronger than C# due to the fact that it is a lower level language. Also DirectX was originally made for C++ so using it in C# would mean that parts are begin cut off. So why C#? [/quote] aside from any ridiculous and pointless arguments over which language is [i] better [/i]. XNA was done in c# for a two reasons. - portability (bytecode level) - security (walled off access to hardware, especially the 360) it has very little to do with language choice (other than ms evangelising c#).
  8. Memory Stomp

    [quote name='Hodgman' timestamp='1296474633' post='4767437'] [size="3"][size=2][/size][/size][b]What's the first thing you suspect may be the problem?[/b] [b]What's the craziest thing you think the problem could be caused by?[/b] [font="arial, verdana, tahoma, sans-serif"][/font][/quote] a) memory stomp pointer aliasing is the pattern that is overwritten consistent? is the pattern that is overwritten a consistent address, or a consistent offset from somewhere else. ill put 2.5$ on memory stomp *after* the memcpy. (or before, and then cleaned up by the memcpy when the assert doesnt fire)
  9. Infinite Loops

    [quote name='Geometrian' timestamp='1296858908' post='4769756'] On Linux, I used GCC with no options specified. On Windows, I used debug mode in Visual Studio 2010 Ult. In release mode, it optimizes away the loop entirely, making the comparison useless. [/quote] profiling anything in debug Is about as useful as sharks on bicycles. in this case, the compiler wont make assumptions about the invariant in the while loop in debug. I'm pretty certain you'll see the same instructions emitted when actually optimised. Aside from this, this is unlikely to *ever* show in a profile, im sure you have much bigger fish to fry.
  10. Quote:Original post by maspeir With C++, typically this would be coded as a single header file, with the vertex class containing both the variables in the C data structure, along with the global variables and actual functions with code instead of prototypes. If there is a .cpp file, it would typically be empty or have empty functions. your lack of data hiding is concerning. If your directly accessing struct members, or global variables, your codebase will be exceptionally brittle, this is not good. use accessors, even in structs. use data hiding, use abstract data types. why? well, next time you want to swap out the array, for a linked list in one of your exposed struct's your going to have to do a hell of a lot of work to fix up everywhere your poking the internals. use accessors, hide your internals. itll make you far more productive. also, dont put all your code in the header file, as this will be included in every file which includes the header, increasing your compilation time. and possibly exe size. use inline and if you really are going to stick with C, for gods sake, use and understand the restrict keyword as for C itself - you end up using function pointers, or switch statements to do exactly what you get with type polymorphism anyway so, your left with either a possible cache miss on a double indirection (vtable lookup) when using c++, or your left with either an instruction cache miss (function pointer) or instruction cache thrash (large switch statement) either way, you get screwed, pick your poison :) the ps3 isnt hostile to oop, it, along with modern architectures where memory latency is much greater than cpu cycle latency, are very sensitive to cache misses, thats all cache, including instruction cache. If you miss cache, your going to spend a lot of time waiting for your data to come back from main memory. but this isnt a reason to avoid c++, its a reason to be careful what you do, and when. If you expect to run a piece of code 100,000 times a frame, you want to avoid any sort of uncached memory lookup at all, including instruction cache. if your doing it 3 times a frame, no one will care either way. - you use abstract data types, and other data hiding mechanisms instead of using class based data hiding. this is more of a style thing, its sometimes nice to be able to encapsulate data and functionality into a single object, sometimes its nice to have functionality separate from any type of data. both approaches are useful, and have their place within a game/engine/other. when you need to do bulk processing, in a typical SoA layout, you want to have your processing in a flatter, ADT style. if your doing things on individual objects, in a typical AoS layout, its far easier to use C++ and leverage the inherent polymorphism. - people are scared of templates. no really, they are. they are like all things, a tool, use them where they make sense, dont use them to fix every problem. and in 13 years of professional life, ive never, ever, seen template metaprogramming in use outside of boost or stl. basically, right now, leverage every language feature you can. you can always rip it out and replace it later if its slow. make it work first, then profile, then fix what's slow. what's *actually* slow might surprise you. and it most likely *wont* be vtable lookups, unless your doing something very wrong.
  11. sorting - fewest swaps ?

    Quote:Original post by vaneger assuming random starting order ? I'm not intending to sort already sorted arrays. pigeon hole sort. it will produce 0 swaps. (as you would keep track of the number times each character that appears, and then just rebuild the array from that). Matt D
  12. when do STL iterators get invalidated?

    the documentation for each container will give you the rules as to when iterators become invalid. check msdn, or the sgi docs.
  13. Language efficiency?

    Quote:Original post by wifesbane Having grown up through the old school path of Pascal, Fortran and C and having worked on aggressive real-time programming (R&D advanced control theory and signal processing) for around 15 years, I am curious as to the use of C++ and scripting languages for games. I see the bookkeeping advantages but wonder how much of an overhead hit you are taking with all of the indirection. From a real-time programming perspective, I can gain a factor of 100 in execution time through careful data and object access management. With modern CPUs and GPUs, is this just no longer an issue in the game industry? rule 1 of performance optimisation - if it doesnt show up on the profile, you dont care about it rule 2 - only tackle the top item of your profile it means little if you are geting a 100x improvement on code which accounts for less than 10% of your overall execution. these days, cache should be a consideration, as should LHS stalls. but in most cases, you wont notice a difference between languages at all. the biggest wins are always algorithmic, instead of piecemeal micro optimisations. by the time you hit those, your starting to scrape the barrel. (and there is a separate conversation regarding performance in terms of execution time, memory use, and the amount of code someone can write, and the amount of bugs in said code, execution time is rarely the only factor at play)
  14. if thats your answer, you've already failed the interview
  15. OpenGL vs. DirectX?

    neither, use glide. *giggles* ok, in reality, it doesnt matter which API you use, both are so similar that its like arguing over whether blue, or a slightly different shade of blue is better. its still fricking blue. learning both is advantageous.