|
Thanks for direction Dave.
I am writing console application which I am planning to schedule on remote server.
I am able to start independent process using my posted code.
But I am not able to start the Process which is coming under Particular service(Means any process which is tightly coupled with Service).
The option I can see here to restart service which will restart related processes. The disadvantage is this activity it will restart my all processes which i don't want to.
let me know your thoughts.
Thanks
|
|
|
|
|
You simply don't have a choice here. Either your app works if started by your Win32_Process code or it doesn't and you have to stop and restart the service.
|
|
|
|
|
yup, Thanks for the Help Dave.
|
|
|
|
|
I have a wrapper class around serial port which looks something like this:
static class HASPCLass
{
private static SerialPort m_port;
private static bool m_initialized;
private static int m_baudRate;
static readonly object _syncObject = new object();
public DoInitialization(int baudRate )
{
lock(_syncObject)
{
if (!m_initialized)
{
Initialize(baudRate);
}
}
}
private Initialize(int baudrate )
{
m_port.open(..);
m_baudRate = baudRate;
m_initialized = true;
}
private Uninitialize()
{
m_port.close();
m_initialized = false;
}
public void Read(byte[] buff)
{
lock(_syncObject)
{
m_port.Read(buff);
}
}
public void Write(byte [] buff)
{
lock(_syncObject)
{
m_port.Write(buff);
}
}
public void Close()
{
lock(_syncObject)
{
if (m_initialized)
{
Uninitialize();
}
}
}
}
I tried making this class thread safe. Someone initializes it - read and writes maybe used from other threads - and in the end calls Close.
Now Imagine I have two additional static methods from other class which do something like this:
public static void function1()
{
HASPClass.Read(...);
HASPClass.Write(...);
}
public static void function2()
{
HASPClass.Read(...);
HASPClass.Write(...);
}
For overall thread safety I also enclosed these functions in locks:
public static void function1()
{
lock(otherlock1)
{
HASPClass.Read(...);
HASPClass.Write(...);
}
}
public static void function2()
{
lock(otherlock1)
{
HASPClass.Read(...);
HASPClass.Write(...);
}
}
Because order in which read and writes are called might be relavant for the serial port/HASP.
My question is: is now my final approach (of using function1 and function2) correct/thread safe? Can I encounter some problems related to threading using function1 and function2?
modified 5-Feb-16 8:08am.
|
|
|
|
|
Locking everything is one way.
Static members are thread-safe as long as they don't access shared resources. The thread creating the serial-class would probably also be the one consuming it; only one consumer per port anyway.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Could you please elaborate your answer, I didn't get you
|
|
|
|
|
Start here[^], and remember that a serial port is not meant to be shared among thread or applications.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Can you please tell me now how all this relates to my question? I have seen posts like the one you linked
|
|
|
|
|
I don't see the need for locking on a static method unless it accesses class-information or a shared unmanaged resource.
Also, adding "lock" everywhere feels like an on error resume tactic
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
you mean locks in HASP class or locks in function1/2?
in function1/2 I added because it can be function1 called read, then function2 called read and write - now function1 calls write - will the output be what I expected? depends on the HASP device.
|
|
|
|
|
Member 12061600 wrote: will the output be what I expected? Yes, as the read would have to finish before something else can be done with the port.
Which HASP dongle are you using? Don't they go by the name "sentinel" these days?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
What kind of serial device requires a read, THEN a write?
|
|
|
|
|
Maybe he's writing code for the server side?
|
|
|
|
|
But what he's got looks like "slave" code; usually in firmware.
The master does the broadcasting (i.e. write) and then expects / awaits an answer (read).
|
|
|
|
|
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.
|
|
|
|