SEH

[ecube]

What's your guys take on SEH handling everything in an application? before I write code to speed test do you think it'll give a big performance drop and are there any benefits of doing this?

[u]

really depends on what type of code will be causing exceptions. After an exception, it takes 3000 cycles to return to execution. Also, if you'd better not be relying on exceptions being thrown when you access an out-of-bounds element of an array - because in most cases that array will have a lot of allocated space after its last element. 
If you could be calling procs by pointers, stored in some struct/var, and it's very rare to have that pointer=0, it could be ok (but you have to mind the resource-allocation, too! - So exception-based code here can become complex or buggy in some cases).

[ecube]

Wow that slow, alright thanks Ultrano, I'll keep that in mind. This is offtopic but I recently found out Mutexs via winapi is really slow aswell

"The test where it really shined is where 6 separate processes were competing for the mutex. These 6 processes first attempted to lock and unlock a Win32 mutex 100,000 times, then attempted to lock and unlock my mutex 100,000 times. The total times were similar for each process, each something like the following numbers:"


Win32 mutex: Took 6800 milliseconds to lock and unlock the mutex
My mutex: Took 240 milliseconds to lock and unlock the mutex

http://www.codeproject.com/threads/opbmutex.asp

interesting project, i'm going to try to implement my own mutex based off his code or ideas as I use mutexs a lot and that's offley slow.

[u]

Try Memory Mapped Files - they are the way to share physical memory among processes. And then.. you can use that 4-byte object of my "fast readersWriterLock" lib/ideas/code - but read the CodeProject topic (get the latest code from there) and read the responses people made, there's the UpgradeToWriter proc that is impossible with my design (thus buggy, thus to avoid). Can't beat it on speed :). And you won't need external dlls.

[P.S]: The Mem-mapped files - don't use a real or temporary file for that, specify a -1 for hFile, and just use a name for the memory-map.

[u]

Code Select Expand


GetGlobalMap proc uses ebx ecx lpszMapName,dwMapSize ;returns a HANDLE to the FileMap, or NULL, EDX=WasCreatedNow
invoke OpenFileMapping,FILE_MAP_ALL_ACCESS,0,lpszMapName
.if eax
xor edx,edx
ret
.endif

invoke CreateFileMapping,-1,0,PAGE_READWRITE or SEC_COMMIT,0,dwMapSize,lpszMapName
.if eax
mov edx,1 ;was created now
ret
.endif

invoke GetLastError
.if eax==ERROR_ALREADY_EXISTS ; if it was created elsewhere while we were trying to create it
invoke OpenFileMapping,FILE_MAP_ALL_ACCESS,0,lpszMapName
xor edx,edx
.else
xor edx,edx
xor eax,eax
.endif
; eax = handle of the filemap
ret
GetGlobalMap endp


In the memory, allocated here, put your mutexes somehow.


Then, I've used this code do get the memory pointer in the current process:

Code Select Expand


OAW_PreloadCtlStruct proc ; makes sure OAWCL_pMap is loaded
local CreatedNow
.data
OAWCTL_hMap dd 0
OAWCTL_pMap dd 0
OAWCTL_NumRef dd 0
.code

.if OAWCTL_pMap
ret
.endif

invoke GetGlobalMap,T("OpenAudioWire_CtlStruct"),OAW_ControlStruct
mov OAWCTL_hMap,eax
mov CreatedNow,edx
OnZero _ret

invoke MapViewOfFile,eax,FILE_MAP_ALL_ACCESS,0,0,0
mov OAWCTL_pMap,eax
.if !eax
invoke CloseHandle,OAWCTL_hMap
mov OAWCTL_hMap,0
jmp _ret
.endif

.if CreatedNow
mov edi,eax
mov ecx,(sizeof OAW_ControlStruct)/4
xor eax,eax
rep stosd
mov eax,OAWCTL_pMap
mov [eax].OAW_ControlStruct.MagicNumber,'OAWC'
.endif
_ret: ret
OAW_PreloadCtlStruct endp


[ecube]

Nice post thanks ultrano i'm going to speed test that againts createmutex is abit  :bg