I have an 8 bit digital output board used for device controlling. Each external device needs one bit and is controlled by a different application.
I have written a class library and the class DigitalOutputPort (VB 2010) that envelopes the driver that manages the 8 bit port. Each device application uses this class, creating its own instance.
In order to set a bit of the digital output port, I have to write a byte to that port: this byte is the bit mask for all 8 bits together: to set HIGH the bit number 0 - 1 - 2, I have to write 7 on the port, to set HIGH all 8 bits, I have to write 256, and so on...
All works fine when only ONE application uses the class. But if two applications want to set its own bit on that port, I get problems because I do not know the current value of all bits set by other applications (the driver has not such function) and, of course, I cannot change one bit without changing all the other (if I do not know the current bit mask)
Normally this looks like a typical case of sharing data between two application and my first idea was to write the current value of the port in a file on the disc, where all application can access and read it. But it seems to be too much heavy for this simple problem. Moreover it could also creates performance ans reliability problem.
Then I though about using a shared field (property) in the class. A shared field preserves its value between all instances of a class: but is it also true between instances from different applications? I cannot find more info about this last point, I have to make same test.
A third way would be that I create just only ONE instance of the class DigitalOutputPort, one for all applications.
The first application that needs it, create the object, all other applications will used the already created object.
I like more than other this way, but I do not know if and how it can be done.
Which should be the right approach in your opinion?
Thank you for replying.
Two different applications will always have distinct and separate memory. So even a Shared field will not be the same. A Shared field is shared only in the context of a specific application and its memory, not globally on the system.
So you need to share data between two applications. There are several options, though the simplest and easiest is the one you mentioned - store it in a file on disk. It's not overkill, since it's a very simple implementation. Just remember not to keep a lock on the file, since several processes will need to access it.
Another possibility you've raised is with a shared instance of DigitalOutputPort. This means having the first application create the instance, and expose it via WCF/Remoting/some other cross-process communication method so that other apps will access it. It's certainly possible (though the state of the DigitalOutputPort will be lost once all of these apps are closed), but it's a lot more complicated, especially if you don't already work with these communication frameworks.
I'd stick to a file on disk, or perhaps a registry key, to store shared, persistent data between applications.
Related
I'm trying to understand ECS. So a component is just plain data, and some manager holds these components in a container and loops through all of them to act on this data, to "update" them.
Is this manager what people call "component-manager" or is it a "system"? Or do they mean the same thing? If not, what does a component-manager and a system do?
ECS means different things to different people. There are a large number of approaches when it comes to implementation but I personally go by the following rules:
A Component is just plain data, typically a structure or some object with no logic associated with it what so ever.
An Entity is a collection of components. It is defined by an identifier, typically an integer, that can be used to look up components like an index.
A System is where all the game logic lives. Each System has an archetype, that is a specific set of components that it operates on. Systems have an update function, which when invoked accesses the specific set of components its interested in (its archetype), for all entities that have that specific collection of components. This update function is triggered externally (by what? see the next paragraph).
Now, here's the bit that addresses your question directly (or at least attempts to). Video games are simulations and they are typically driven by whats called an update loop (typically sync-ed to a monitor's refresh rate). In ECS architecture, there is typically dedicated code that strings your systems together in a queue and on each time-step of the update loop executes those systems in sequence (ie. calls their update functions). That bit of dedicated code not only manages the system update loop but is also responsible for managing components (stored as lists/arrays that can be indexed by an entity id) and a myriad of other tasks. In many implementations its referred to as the "Engine". This is what I take to be a "component-manager". But that could mean something else in another ECS approach. Just my two-cents. Hope it helped.
I understand what serialized is. I simply do not know when I would use it. I have seen the discouraged practice of session data in a database and things like that but other than that I do not know.
What kind of objects state would I save in a database, file system, anything that needs persistence? Why would I use it for a non-"permanent" reason?
I do not have a context per se. All I really do are client server web apps. I may get to use a Java stack for it, but I'd really like to understand this part of things, should I need it.
I have asked similar questions. I'm just not understanding.
In a sentence, using a generic serialiser is a reasonable way to save stuff to disk, move stuff over a network in a manner which doesn't require you to design a data format, write code that emits data in that format, and write a parser for that format (all error-prone) by hand.
Any time you want to persist an object (or object hierarchy) beyond its existence inside a single execution on a single machine, you are going to want to serialise and deserialise.
Some scenarios that come to my mind are
Caching: when you want to offload in-memory objects to disk (the caching framework can serialise the object to disk)
For thick clients (either a desktop application or an app using RMI) you'll need to transfer objects from one JVM to another, and this is done by serialising them
I can't think of any other scenarios from the top of my head.
I have two classes, Server and Application, with a many-to-many relationship: a server can run multiple applications, an application can run across multiple servers. A third class, Host, represents a single application on a single server, including references to the Application and Server objects as well as additional data such as the amount of disk space used by the application on the server. Both Server and Application objects contain a list of all their hosts: hence, Applications know about Hosts and Hosts know about Applications, and Servers know about Hosts and Hosts know about Servers.
The purpose of my project is to work out the schedule for migrating a bunch of applications onto new servers. Originally each application had a migration-start and migration-end date. Some applications also have start and end dates for virtualisation. Virtualisation occurs if the migration cannot be performed within the application's constraints (never mind what these are). It occurs prior to the migration and frees the application from its constraints. An object called 'Schedule' is held by the Application object, which includes these 4 dates as well as a boolean flag to say whether it is to be virtualised, and a list of 'months' which contain the man-hours required to migrate (or virtualise) the application in each particular month.
We now want to allow servers to undergo virtualisation separately, on a specified date. All the applications (or parts of applications, i.e. hosts) on these servers will be virtualised on this date; they will be migrated along with the rest of the application. We originally decided to have the server class hold its own Schedule object. The virtualisation dates were then set in the server. However, we decided we wanted to keep the server and application schedules consistent - so that, for example, the server schedule's migration-start and end dates should be set to the earliest start and latest end dates, respectively, of all applications running on that server. This meant that every time we updated the Application dates, we had to remember to update all its server dates (via the host object). Or, if we wanted to update the Application's man-hours for a particular month, we had to update the server's man-hours also.
Then we thought about putting a single Schedule object inside each Host object. This solves the consistency problem, but leads to quite a bit of redundancy: since all Host objects belonging to an application will necessarily have the same migration dates (but possibly different virtualisation dates), when you set the migration dates for an app, you have to set the same dates for every host. Also, there are a few instances where we need to work out the earliest-start and latest-finish dates for servers AND applications, as above. This would involve either: holding this data in each of the application and server objects (effectively giving each its own Schedule, thereby brining back problems with consistency), or: calculating this data on-the-fly each time it is needed, by looping through all the hosts' schedules. The same goes for the man-hours required by an application each month, which is calculated at the application level, fractioned into hours for each host per month, and then recalculated when we need to figure it out at the application level again. This is, as you would expect, not efficient in the slightest.
This isn't a straightforward question, but I'm wondering if there are any accepted strategies for dealing with this sort of situation. Sorry in advance for the prolixity of my post; hopefully I've made the situation clear enough.
This is complex once we get into 3rd paragraph onwards
I will use the following design principle
Keep Application, Server, Host objects contain the minimum required behaviors and states.
For example, Application Object may contain start date, end date and virtualization start and virtualization end dates. Think whether it require to contain a list of servers? or instance of Host?
Then a think about a small frame work like this.
a) MigrationManager who does the complete process of Migration using List
b) MigratioContext will composite information for migration process.
c) ErrorContext will composite the error and exception handling
Migration Manager gets an instance of Scheduler and schedules the migration
In this way we can gradually evolve a frame work kind of stuff around the core business object and business logic.
The important thing to remember
Separation of Concerns.
Reusability of Code: For exmple Your Application object may not be required to tied up the whole migration process. Instead those things can be done by another object
(This answer is based on my high level understanding and assumptions that could be wrong. But I think you may get some directions to build the application to meet the requirements)
Once more suggestion I have. Use a Modeling Tool such as StarUML or ArgoUML to put your ideas in a pictorial form. This will help all of the members to get into the question very quickly.
Thanks
I think a fundamental principle of object-oriented programming is that to the extent possible, every mutable aspect of state should at all times have exactly one well-defined owner (that owner may, in turn, be owned by exactly one other entity, which is in turned by one other entity, etc.). Other objects and entities may hold references to that mutable state, but any such references should be thought of in terms of the owner. For example, if a method accepts a reference to a collection and is supposed to to populate it, the method would not think in terms of operating on a collection it owns, but rather in terms of operating on a collection owned by someone else, for the benefit of that entity.
Sometimes it is necessary to have various objects to have separate copies of what is supposed to be the same mutable state. This situation frequently arises in things like graphical user interfaces, where an object might "own" the rotational angle of an object, but a display control might need to cache a private rendering of that object in its current orientation. Handling of such cases may be greatly simplified in cases where one object is designated the absolute master, and it keeps other objects notified of its state. It will be greatly complicated if there are multiple objects, none of which has exclusive ownership, but all of which are supposed to nonetheless keep in sync with each other.
If you can work your model so that no piece of state needs to be duplicated, I would highly recommend doing so. It's crucial, though, that your model be capable of representing all scenarios of interest, including the possibility that two things which are supposed to be in the same state, might not be. What's most important is that every aspect of state has a well-defined chain of ownership, so that when an aspect of state is changed, one can say whose state is affected.
I would like to create/use a system-wide independent universal 'counter object' that can be called via COM in a thread-safe manner.
The counter object will be passed an ID to identify which counter to return, handle the counting, 'persist' the count (occasionally), have reasonable performance (as fast as possible) perhaps capable of 1000 counts per second or better (1mS) and be accessible cross-process/out-of-process. The current count status must be persisted between object restarts/shutdowns.
The counter object is liklely to be a 'singleton' type object implemented in some form of free-threaded dictionary, containing maybe 10 counters (perhaps 50 max). The count needs to be monotonic and consistent, (ie: guaranteed unique sequential values).
Each counter should have a few methods, like reset, inc, dec, set, clear, remove. As a luxury, I would like to have a variable-increment (ie: 'step by' value). To support thread-safefty, perhaps some sorm of critical-section or mutex call. It just needs to return a long/4byte signed integer.
I really want something that can be called from anywhere, including VBScript, so I figure COM is my preferred solution.
The primary use of this is for database keys. I am unable to use autoinc or guid type keys and have ruled out database-generated counting systems at this point.
I've spent days researching this and I have really struggled to find a solution. The best I can find is a free-threaded dictionary object that can be instantiated using COM+ from Motobit - it seems to offer all the 'basics' and I guess I could create some form of wrapper for this.
So, here are my questions:
Does such a 'general purpose
counter-object already exist? Can you direct me to it? (MS did
do an IIS/ASP object called
'MSWC.Counter' but this isn't
'cross-process'/ out-of-process
component and isn't thread-safe. (but if it was, it would do!)
What is the best way of creating such
a Component? (I'd prefer VB6
right-now, [don't ask!] but can do in VB.NET2005
if I had to). I don't have the
skills/knowledge/tools to use
anything else.
I am desparate for a workable solution. I need specific guidance! If anybody can code something up for me I am prepared to pay for it.
Update:
Whats wrong with GUIDs? a) 16bytes if I'm lucky (Binary storage), 32+bytes if I'm not (ANSI without formatting) or even worse(64bytes Unicode). b) I have an high-volume replicated app where the GUID is just too big (compared to the actual row data) and c) the overhead of indexing and inserts d) I want a readable number! - I only need 4 byte integer, so why not try and get that? I know you will say that disc-space is cheap, but for my application the cost is in slow inserts, and guids don't help (and I have tried/tested) but would prefer not to use if I have a choice.
Autonumber/autoincs are evil: a) don't get the value until after the insert, b) session specific, c) easy to lose/screw up on a table alter, d) no good for mutli-table inserts, (its not MS-SQL Svr) plus I have a need for counters outside my DB...
By the sound of it, what you're looking to create is an ActiveX EXE. They run in their own process but can be accessed from any other process by instantiating an object from it as though it is just another COM object. It handles all the marshaling necessary to sync its internal thread with the threads of any process calling it. Since all you planning on using is integers, there's no need to worry about the thread safety of objects passed between the threads.
More than likely you can use the MSWC.Counter object within that ActiveX EXE and let it do the counter work.
A database engine is already very good at generating unique primary key values for a dbase table. Either by marking the column auto-increment or by using a Guid. Trying to create your own is a grave mistake. System wide is just not wide enough, it fails miserably when your app grows and more than one machine starts using the database.
Nevertheless, you can get what you want in VB6 by creating a COM server. It's been to long, I forgot the exact names of the project options, something resembling "single use".
I have implemented a similar solution implemented as a REST web service - accessible from any technology that supports http.
Simple c sharp backend implementation using a singleton pattern and will scale nicely under IIS.
The whole thing sounds like a twisted idea, so why should I not add another twisted one. :P
Host an old-skool ASP page.
You can use Application.Lock with a counter then, just like in the sample.
Added benefit: use it from any platform/language. (e.g. other HTML pages with XMLHttpRequest. :)
If you save the value at say every 100th request to a file, you do not even have to worry about IIS resets.
Just set the starting value to last saved value + 100 in Application_OnStart. :P
I created this simple textpad program in WPF/VB.NET 2008 that automatically saves the content of the forms to an XML file on every keystroke.
Now, I'm trying to make the program see the changes on the XML file in realtime.. example, If I open two of my textpads, when I write on the first one, it will automatically reflect on the other textpad.
How can I do this?
One of my colleagues told me to read about iNotifyPropertyChanged (which I did) but how can I apply it to my application..?
:( help~
btw, I got the idea from a Google Wave demo, and I'm actually trying to do something bigger..
Note - this approach will be really, really expensive in terms of disk I/O, memory usage and CPU time. Why are you using XML is that the native format of the data you are editing? You may want to look at a more compact format - one that will use less memory, generate fewer I/Os and use less CPU.
Also note that you writer may need to flush the file for the watcher to notice any changes. This is expensive as well - especially if you re doing it on every key stroke.
Be sure to use the correct file open attributes (sharing, reading and writing).
You may want to consider using shared memory to communicate between your processes. This will be less expensive. You can avoid large ammounts of disk I/O by only writing changes to disk when the use asks to commit them, or there is a hint to do so. I suggest avoiding doing this on every key stroke.
Remember, your app needs to be a good system citizen and consume a reasonable amount of system resources. This is especially true running on netbooks and other 'low spec' systems.
You will probably need to use the FileSystemWatcher to watch the file on the disk rather than a property in the running instance of the application.
Or you could use some custom message passing between different instances of your application.
INotifyPropertyChanged isn't going to work for your application. That interfaced is used when data binding some element to a UI object.
Your best bet is going to be to attach a FileSystemWatcher to the file when you open it for editing. You can then use the change events to reload the file as needed in each instance of your application.
This will also load changes made from external editors.
It sounds like you are using file IO as a form of interprocess communication, if so, IMO you need to rethink your design, especially if you are doing something "bigger" than google wave (whatever bigger means in this context) as what you are proposing is terribly ineficient.
Do some searching on Interprocess communication and you will get a whole bunch of idea's #foredecker's idea (+1) of shared memory is a good possibility for example.