Forum ‹ C# ‹ Statics Disallowed and Workarounds

[AaronSDG]

I understand that static variables are disallowed, and I understand the reasoning. Being new to this type of massively parallel programming, what is the best practice for tracking this type of global information? For example, I want to use BigDB to coordinate my various chat server rooms so they all appear to be in the same space. I would want to flush the database when the last room is closed. My first instinct was to have a static object counter that incremented and decremented with each DLL instance. When "GameClosed()" was called on the last room, it would flush the DB then shut down. Perhaps this is not the right approach in this environment. I'm used to coding single-player and asynchronous types of games. This is my first foray into synchronous multi-player systems.

Then there is the issue of threading. Normally I would use a generic "locker" object, since locking on "this" or "typeof" is not generally wise:
static readonly object locker = new object();

What is the preferred way to manage thread locking in the PlayerIO framework?

Thanks!
Aaron

[Oliver]

Hey Aaron,

I'm sorry, but i don't quite understand what you're trying to achieve.

Do you want one massive chat room that all your online users are in (potentially thousands)?

- Oliver

[AaronSDG]

Essentially, yes. It seems to me that all my ChatServer instances would accept chat messages and store them in a BigDB table keyed by date and time. Individual instances would track the time of the last message they broadcast and would poll the DB for messages newer than that timestamp. When it finds them, it would update its "last message broadcast" stamp and broadcast the newer messages.

I could build in a "delete all messages older than an hour" routine into the DLL when people join or something, but when the last chat room closes, there would still potentially be messages lying around. Now, as I thought about it yesterday, this isn't necessarily a major deal. Perhaps it's just my OCD. Ideally, when the last room instance closes down, it would flush the chat database. Without static variables, I'm not sure how any single instance could be sure it's the last one when it closes.

The other question was regarding threads. [Edit: I snipped this question. Since any threading would be restricted to a single Game<P> instance, I can use a private var for my locker. It doesn't need to be static.]

Cheers!
Aaron

[Oliver]

Hey,

Yes, you can build it like that.

The whole "who-closes-last" is a non-issue, just have the every room delete old (>1 hour) messages when it closes. It doesn't matter if multiple rooms delete old messages, since it'll just be a an index delete i suppose.

- Oliver