|
Right; that's what I meant by "server".
|
|
|
|
|
Fair enough ... just never used serial com in a "client-server" setup; only master-slave.
For example, a printer only prints when you tell it to; it doesn't ask for something to print (usually).
A scale tells you the weight only when you ask.
etc.
|
|
|
|
|
Potato / potatoe.
One of the first serial devices I wrote software to communicate with was actually a fairly large specialized computer that performed analyses of gasses.
But most serial devices I encountered were smaller, e.g. a coin counting machine, a magnetic card encoder. Good times.
|
|
|
|
|
But I still don't know if OP is writing client code or server code ...
|
|
|
|
|
Can we at least agree he's writing bad code?
I expect the examples he posted are just for reference and shouldn't be taken literally.
|
|
|
|
|
hipotethical - its not important in reality it could be other way round(first write then read), but my question still holds.
|
|
|
|
|
Hypothetically then, I see deadlocks.
|
|
|
|
|
So can you please explain to me how and why you see deadlocks?
|
|
|
|
|
I don't deal in hypotheticals.
|
|
|
|
|
assume it is first write then read. I can't recall the protocol. But why does it matter for the thread safety? I gave all the information.
The principle remains: function1 and function2 have their code locked.
HASP class has read and write locked too.(with a different lock though).
|
|
|
|
|
It seems OK for what you describe, but I doubt that your HASPclass should be static; that seems like a poor design.
Oh, and I would expect Initialize to be public and DoInitialize to be private . Or maybe what you have as DoInitialize should be named Open or Connect ?
modified 5-Feb-16 22:04pm.
|
|
|
|
|
yeah openport or smth like that is better name.
why HASPclass being static is bad idea?
|
|
|
|
|
Because you can't guarantee that you will never need more than one.
|
|
|
|
|
I will find out if I need acess to more than one port. Other than that is my setup ok?
|
|
|
|
|
Quote: I will find out if I need acess to more than one port
It's not just about what you need right now; it's about what anyone might need any time in the future.
Consider the possibility that you will write an article about it here on CP, and five years from now someone wants to use it, but needs to access multiple ports. And it may not only be HASP; perhaps someone wants to use your code for other types ports.
Do not limit the flexibility of your code unless you have a very good reason to do so. "I don't need it right now" is not a good reason.
Quote: Other than that is my setup ok?
I can't make a judgement on that.
|
|
|
|
|
No I mean my original question the HASP class and how I use it in function1 and function2 is it thread safe? that is what I meant. Some people comment here they see deadlocks. and I am confused.
|
|
|
|
|
Message Closed
-- modified 5-Feb-16 4:55am.
|
|
|
|
|
If, by this, you mean can you create a Kiosk using C# then yes you can. Microsoft even publish a sample[^] to show you how to do this.
This space for rent
|
|
|
|
|
|
|
I'll look forward to March's instalment then.
|
|
|
|
|
I understand this code: [^]
class Base
{
public static void F() {}
}
class Derived: Base
{
new private static void F() {}
}
class MoreDerived: Derived
{
static void G() { F(); }
} And, I can follow MS's explanation:
"In the example above, the declaration of F in Derived hides the F that was inherited from Base, but since the new F in Derived has private access, its scope does not extend to MoreDerived. Thus, the call F() in MoreDerived.G is valid and will invoke Base.F." But, in terms of why method over-riding with 'new is defined as limited in scope in terms of inheritance: I can't say I understand that. And, I am curious about that ... note that my working assumption is that the creators of C# are (infinitely) smarter than I'll ever be, and had good reasons to make the design decisions they did.
While I think the right way to achieve method "hiding" in the context of inheritance is using Interfaces, I also have (as some QA posters express it) "a doubt" about that.
To make this less "theoretical," let me pose a scenario where you have a class where the constructor has a boolean flag; and, you have methods in the class some of which you would like to be unavailable depending on the value of the boolean flag:
public class SomeClass
{
private bool HideThis;
public SomeClass(int someInt, bool hideThis = false)
{
HideThis = hideThis;
HideThat = hideThat;
}
public void Method1(int someint)
{
if(HideThis) return;
}
} An obvious strategy is just to use a flag to skip executing code in a Method (as shown above). But, what would be interesting is some code where the constructor of the Class is, somehow, a "factory" and returns a class with/without a given method depending on the boolean flag.
While I am sure you could use reflection and compiler services, to generate classes on-the-fly, I would not want to use that unless that was absolutely required for other reasons. And, using System.Dynamic is another route I avoid. I am also aware of using the "Obsolete" attribute to make methods non-browsable; and, that's another place I don't want to go.
The various "factory method" patterns I've seen do not seem to me be usable for this type of scenario ... unless you are willing to do specific casting of the whatever new "object" is returned from the factory to a specific Interface.
thoughts ?
«In art as in science there is no delight without the detail ... Let me repeat that unless these are thoroughly understood and remembered, all “general ideas” (so easily acquired, so profitably resold) must necessarily remain but worn passports allowing their bearers short cuts from one area of ignorance to another.» Vladimir Nabokov, commentary on translation of “Eugene Onegin.”
|
|
|
|
|
Similar example as your found in the IDbConnection-classes; simplified, there's a property that shows the connection-state. Calling a method when using the wrong state will result in an exception offcourse.
..but yes, pass the boolean as a parameter and you can create a factory that returns either a class with five or one with seven members - but please don't abuse the constructor for that. Your construction-method is no longer part of the class being created.
Having seen the questions on CP on how to hide a proprerty from the UserControl-class, I still fail to see the value of hiding a public class-member. Simply make it private if you don't want it.
Make it private in the base, and implement it only on one of the inherited classes; that's not exactly hiding, that is simply not providing a method when it is not needed.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
BillWoodruff wrote: why method over-riding with 'new is defined as limited in scope in terms of inheritance That's only in conjunction with the private modifier. If it wasn't private then the new method's scope would extend to derived classed.
Do you have a real life scenario where you think you need method hiding or "something like that"? I have yet to find one - there was always a way to design it in a way that does without method hiding. (State-dependent method availability sometimes is neccessary of course.)
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
BillWoodruff wrote: But, in terms of why method over-riding with 'new is defined as limited in scope in terms of inheritance: I can't say I understand that.
It certainly looks weird, but to me it looks like since "new" is supposed to work together with access identifiers, it should play nice with all of them. Or, simply not have access identifier, and just inherit it from the Base class' method - which now that I think of it, probably would have mad more sense *
Having said that "it should play nice", I think the default behavior for new private is the right one - what else should it do?
* inheriting from Base method might not work either, because we can have several methods with the same name, and they each can have their own access identifier. So, it would need to inherit the one with the same signature as its own.
Best,
John
-- Log Wizard - a Log Viewer that is easy and fun to use!
|
|
|
|