SysTool Shared Memory info

[W1zzard]

Shmem for Sensors​

Effective since Build 512

/* CSensor::SENSOR_TYPE definition copied here for reference

typedef enum SENSOR_TYPE {	
	sUnknown, 
	sNumber, 
	sTemperature, 
	sVoltage, 
	sRPM, 
	sBytes, 
	sBytesPerSecond, 
	sMhz, 
	sPercentage, 
	sString, 
	sPWM 
}; */

#define SH_MEM_VERSION 1
#define SH_MEM_NAME "SysToolSensors"

#define SH_MEM_MAX_SENSORS 128

struct SHMEM_SENSOR {
	WCHAR m_name[255];	// Sensor name
	WCHAR m_section[64];	// Section in which this sensor appears
	CSensor::SENSOR_TYPE m_sensorType;
	volatile LONG m_updateInProgress; // this is 1 when systool is writing to the sensor
	UINT32 m_timestamp;	// GetTickCount() of last update	
	VARIANT m_value;

	WCHAR m_unit[8];	// Unit for text output
	UINT8 m_nDecimals;	// Default number of decimals for formatted output
};

struct SHMEM {
	UINT32 m_version;	// Version of shared memory structure
	UINT16 m_nSensors;	// number of records with data in m_sensors
	SHMEM_SENSOR m_sensors[SH_MEM_MAX_SENSORS];
};

 

[_xhp_]

Looks ok...

the only thing you could change is volatile LONG m_updateInProgress - not the right way of doing the synchronization (it will probably be ok 99% of the time, but...). Named semaphore would be better (but slower)...

I wrote the plugin for Samurize using the upper data. It seems to be working...
If this data structures will not be changed I'll post it here...

 

[_xhp_]

From MSDN:
"To fully close a file mapping object, an application must unmap all mapped views of the file mapping object by calling UnmapViewOfFile, and close the file mapping object handle by calling CloseHandle. The order in which these functions are called does not matter. The call to UnmapViewOfFile is necessary because mapped views of a file mapping object maintain internal open handles to the object, and a file mapping object will not close until all open handles to it are closed."

So what would happen if the systool decided to exit and UnmapViewOfFile/Closehandle on the shared memory, BUT a plugin did not call UnmapViewOfFile (becouse it is reading the memory)... The systool would close, but the memory would not be released, plugin would still detect the memory is there and constantly read the same memory...

If the upper text is correct continue reading (if not, please ignore the whole post):
You could add a flag to the header. It could be 1 is the systool is running, 0 is it is not running... This way if the memory reader detects 0 it knows the values are old/invalid... It could also call CloseHandle on the memory (I am not sure is this is possible... Can one process CloseHandle on the handle created by another process?)

EDIT: ok, I checked and the upper text is not correct Disregard everything I said

 

[W1zzard]

i'm using interlockedexchange with the variable as long as i'm the only one writing to it and the other processes are only reading from it this should be ok .. using more complex synchronization is not worth it. worst case is that the app reading from the shmem gets false data for one read.. the next read will probably be correct

 

[W1zzard]

if systool crashes it cant set the value to 0 that's why there is the timestamp for each sensors.
following scenario is also possible. user disables a plugin and hits apply. now less sensors exist in the shmem.

what do you think about setting # of sensors to 0 on exit?

 

[W1zzard]

actually having a variable "systool running" in there might be useful .. any idea for the on-crash situation?

 

[_xhp_]

I wasnt completly exact. In the upper text plugin = shared memory reader... And I was wrong . There wont be any problems in the upper scenario...
I tought there would be becouse I saw that rivatuner in the samples that read rivatuner's memory differenciate between the alive and dead state of rivetuner. Rivatuner also has a flag in the header that shows if it is alive or dead... I tought there must be a reason for this (and maybe there is but I cant see it anymore)...

 

[W1zzard]

i'll talk to unwinder about this after the weekend

 

[W1zzard]

i talked to unwinder:

RT is started -> Shared memory is allocated -> Other app using shared memory is started -> RT is closed

Other app uses this check to determine if shared memory is no longer valid

 

[_xhp_]

Seems I was partialy correct...

You should add a flag like that to the shared memory too.

There will be no problem if the aplications that read the shared memory do it like this:

void OnTimer() // or something else
{
OpenFileMapping
MapViewOfFile
// read
UnMapViewOfFile
CloseHandle
}

I used the upper way in the samurize plugin.

But, there is a better way to read the shared memory where you call OpenFileMapping and MapViewOfFile only when initialising and UnMapViewOfFile and CloseHandle uninitialising (or something similar):

OnLoad
{
OpenFileMapping
MapViewOfFile
}
OnDestroy // exit
{
UnMapViewOfFile
CloseHandle
}
OnTimer // or something else
{
//read
}

The problem is that this won't work with the current shared memory layout if the following occures:
Systool is started -> Shared memory is allocated -> Other app using shared memory is started -> Systool is closed - if the second way is used reading the shared memory will still succed with the values that that were present at the time systool exited.

What we need is:

OnTimer // or something else
{
if (readSystoolAlive == alive)
{
//read
}
else
UnMapViewOfFile
CloseHandle
}