C / C++ / MFC

20-Mar-18 5:13

I'm attempting to port some old code from VS2005 C++ to VS2017. One problem that I don't know how to address is how to convert the old _beginthreadex to what would be the correct call in 2017.

VS2005 code is calling a member function that is in a class:

m_sendThread = (HANDLE)_beginthreadex(NULL, 0, sendData, this, 0, &this->m_sendThreadId);

I've casted it it to: m_sendThread = (HANDLE)_beginthreadex(NULL, 0, (unsigned(__stdcall *)(void *))sendData, this, 0, &this->m_sendThreadId);

Code compiles but will exit with code 1073741855.

The class is a class that handles winsock connections and sendData is called to start the thread once the socket has been established.

I am new to classes and even newer to threaded programs so it is hard for me to say how to fix this problem.

Any help would be much appreciated.

Thanks.

Jochen Arndt20-Mar-18 5:43

Jochen Arndt

20-Mar-18 5:43

The _beginthreadex() version used by your code has not changed since VC 6.0 besides the return type:

VS6: _beginthread, _beginthreadex[^]:

unsigned long _beginthreadex( void *security, unsigned stack_size, unsigned ( __stdcall *start_address )( void * ), void *arglist, unsigned initflag, unsigned *thrdaddr );

_beginthread, _beginthreadex | Microsoft Docs[^]:

uintptr_t _beginthreadex( // NATIVE CODE
   void *security,
   unsigned stack_size,
   unsigned ( __stdcall *start_address )( void * ),
   void *arglist,
   unsigned initflag,
   unsigned *thrdaddr
);

If you need to cast the start_address parameter (your sendData function) to avoid compilation errors, you should change the function declaration instead. Never use casting for such (address of function) parameters but provide correct types.

An exit code of 1073741855 (0X4000001F) is not a standard error code. You might use the debugger to find out when and under which conditions your application exits with that code.

I guess that the problem is not related to _beginthreadex() but to the thread function itself or even any other parts of your application.

jimNLX6-Apr-18 9:03

6-Apr-18 9:03

Thank you for your time and response. I didn't know this was responded too as my email has an issue.

leon de boer20-Mar-18 8:00

20-Mar-18 8:00

You are calling a class member function you must shim it thru a static function

C++

#include <process.h>  
class foo
{
public:
	void startTheThread()
	{
		// Start the thread for the sendData (we send "this" in as a parameter for shim)
        // The shim code is a static block for all your class instances hence &foo::sendData 
        // It creates a class member call from the value of "this" passed in 
		sendHandle = _beginthreadex(0, 0, &foo::sendData, this, 0, &this->m_sendThreadId);
	}
private:
	void sendDataMemberCall()
	{
		/* All the real send code goes here */
	}

	static unsigned __stdcall sendData(void *p_this)
	{
		/* This is just a shim to convert a thread call to a member function call */
		foo* p_foo = static_cast<foo*>(p_this);
		p_foo->sendDataMemberCall(); // call Non-static member function!
		return 0;
	}
	uintptr_t sendHandle;
	unsigned m_sendThreadId;
};

As a quick explaination a non static class function has a hidden invisible pointer which you know as "this".
So if you look at the member function sendDataMemberCall it looks like this to you

void sendDataMemberCall()

At a code level it actually looks like this

void sendDataMemberCall (foo* this);

The compiler pushes down a hidden pointer to the actual instance of the class object
So if we had two instances foo1 and foo2 when you call sendDataMemberCall they actually do this

sendDataMemberCall (&foo1);
sendDataMemberCall (&foo2);

So the problem is the format we need for the thread function doesn't match the class function and we can't
make them match because of the hidden local instance push. However the thread function does allow us to pass
a parameter and we pass "this" as a parameter. So now what you can do is typecast this back to a pointer to
it's type and get the compiler to call the pointer member function and it will magically push our hidden pointer.

So all the shim is really doing is turning function + extra parameter into push paramater call class function.

In vino veritas

modified 20-Mar-18 20:50pm.

jimNLX6-Apr-18 9:06

6-Apr-18 9:06

Thank you for the response. Just getting back to working on this and will look over and try to fix with your suggestions.

jimNLX11-Apr-18 9:03

11-Apr-18 9:03

Thanks again for the detailed response.

I attempted to apply this calling convention into my program and really got twisted up with outer errors. So I'm trying now to do this again.

Still getting errors:
error C2664: '_beginthreadex' : cannot convert parameter 3 from 'unsigned int (__clrcall *)(void *)' to 'unsigned int (__stdcall *)(void *)'

Address of a function yields __clrcall calling convention

Confused | :confused:

Jim

leon de boer17-Apr-18 21:45

17-Apr-18 21:45

The compiler is trying to link to managed code ... see the 4 different definitions of beginthreadex
_beginthread, _beginthreadex[^]

You are probably compiling with the managed code probably because you have clr compilation turned on.

pull down menu .... debug -> program name properties -> general tab -> No Common Language Runtime Support

Turn it to "No Common Language Runtime Support"

If you dont understand managed vs native code
Difference between managed and unmanaged code[^]

Now the funny part if you do need managed code you will have to shim the shim ... yes an irony but the pointer that is being passed has to be converted. If you can't work it out drop me a line and I will do it for you.

In vino veritas

modified 18-Apr-18 3:53am.

jimNLX18-Apr-18 3:49

18-Apr-18 3:49

Thank again Leon.

Seems like anything I change in the compiler just makes things 1000 times worse. I looks like there is going to be no easy way to get this to work and I may have to take a couple of classes to get up to speed.

Thanks for all your time and thorough answers.

Jim Confused | :confused:

leon de boer18-Apr-18 15:27

18-Apr-18 15:27

No it's not that hard it means your code contains managed code (that is all the pointers are garbage collected), so put the settings back. I can't tell because I have no idea what the code itself looks like or does you just gave us a small piece.

So all the issue is that you have managed code and you need the pointer to be passed to beginthreadex to be a managed pointer and if you want me to create the shim I can.

In vino veritas

jimNLX9-May-18 9:18

9-May-18 9:18

I really wish I didn't have to keep dragging this one, but I still don't know why this won't work.

It worked perfectly fine in VS2005, but now I can't make a thread? Doesn't make sense.

From what I have learned the original code was built with /CLR:pure or managed. I've tried to remove this but the error are so extensive I don't think I would ever get through them.

Is there another function I can use to create the thread? Or some other way to get this thread to run without rewriting the whole thing?
Any help would be much appreciated.

This is where I'm at now:
#include "Connection.h"
#include "Packet.h"
#include "Opcodes.h"

using Ig::Connection;
using Ig::CriticalSection;

using namespace Ig;

CriticalSection::CriticalSection()
{
...
Connection::Connection()
{
...
}

Connection::~Connection()
{
// Wait for the thread to exit.
exitThreads();

// Clear any pending opcodes.
clearPendingOpcodes();
}

bool Connection::open(const char* ip, const int port, const int timeOut)
{
// Make sure the threads are not already running.
exitThreads();

// Setup the ports

// Setup the sockets.

// Set the receive socket timeout.

// Set up the send address.

// Setup the receive address

// Change the state to connecting

// Connect to the sender address.
if (::connect(m_sendSocket, (sockaddr *)&m_sendAddress, sizeof(m_sendAddress)) == SOCKET_ERROR)
{
int error = WSAGetLastError();
closesocket(m_sendSocket);
return false;
}

// Bind to the receiver address.
if (::bind(m_receiveSocket, (sockaddr *)&m_receiveAddress, sizeof(m_receiveAddress)) == SOCKET_ERROR)
{
int error = WSAGetLastError();
closesocket(m_sendSocket);
closesocket(m_receiveSocket);
return false;
}
// Clear pending opcodes.
clearPendingOpcodes();

// Start the threads
// THIS IS WHERE ALL MY PROBLEMS BEGIN!!!!!!!!!!!!!!!!!!!!!!!!!!!!
// //
m_sendThread = (HANDLE)_beginthreadex(NULL, 0, sendData, this, 0, &this->m_sendThreadId);
m_receiveThread = (HANDLE)_beginthreadex(NULL, 0, receiveData, this, 0, &this->m_receiveThreadId);

return true;
}

unsigned int Connection::sendData(void* param)
{
bool request_thread_exit = false;
ConnectionState state = Connection::connecting;

// The param should be an instance of the connection class.
if (param == 0) return 0;

// Cast it to a connection
Connection* connection = static_cast(param);

// Set the state to connecting.
connection->setState(Connection::connecting);

// Loop until we are told to exit.
while (state != Connection::offline)
{
// Get the current state (thread safe).
state = connection->getState();

// Send data based on the state of the connection.
switch (state)
{
// The connection is offline.
case offline: break;
// Connecting to the Ig.
case connecting: connection->processConnectingState(); break;
// Loading everything.
case loading: connection->processLoadingState(); break;
// Waiting for the Ig to set load flags.
case waiting: connection->processWaitingState(); break;
// Running.
case running: connection->processRunningState(); break;
// Unloading.
case unloading: connection->processUnloadingState(); break;
// Disconnecting.
case disconnecting: connection->processDisconnectingState(); break;
}

// Take a break...
Sleep(15);
}

// Close the socket.
closesocket(connection->m_sendSocket);

return 0;
}

unsigned int Connection::receiveData(void* param)
{
bool request_thread_exit = false;
ConnectionState state = Connection::connecting;

// The param should be an instance of the connection class.
if (param == 0) return 0;

// Cast it to a connection
Connection* connection = static_cast(param);

DWORD lastResponseTime = GetTickCount();
DWORD elapsedTime = 0;
const int max_buffer_size = 66000;
char buffer[max_buffer_size];
DWORD maxTime = (DWORD)connection->getTimeOut();

while (state != Connection::offline)
{
// Get the current state (thread safe).
state = connection->getState();

// Attempt to receive data.
int bytes_received = recv(connection->m_receiveSocket, buffer, max_buffer_size, 0);
if (bytes_received != SOCKET_ERROR)
{
// Update the response time.
lastResponseTime = GetTickCount();
// Process the Response.
connection->processResponse(buffer, bytes_received);

//If the state is connecting, then transition to the loading state.
if (state == Connection::connecting)
connection->setState(Connection::loading);

}
else
{
// Check how long it has been since we have received a response.
// If it has been to long, then transition to the offline state.
elapsedTime = GetTickCount() - lastResponseTime;

// Make sure the timer didn't roll over.
if (elapsedTime maxTime && (state > Connection::connecting && state setState(Connection::offline);
}
}
}

// Close the socket.
closesocket(connection->m_receiveSocket);

return 0;
}

void Connection::exitThreads()
{
...
}

}

leon de boer9-May-18 16:11

9-May-18 16:11

Patched code.

Exchange/MSNRouteEditor_VS2017.zip at master · LdB-ECM/Exchange · GitHub[^]

In vino veritas

jimNLX11-May-18 6:23

OpenCL bit-matrix multiplication (implementing tiling in local memory)

11-May-18 6:23

Leon,

Thank you for all your help with getting this working.

Jim

User 1370349219-Mar-18 19:19

Re: OpenCL bit-matrix multiplication (implementing tiling in local memory)

19-Mar-18 19:19

Hello all

I am performing multiplication between two square bit-matrices using a specific formula (not the dot product of row/col, I will describe it below). My implementation works correctly but it blows up when I attempt to do tiling in the local memory. Even though I understand the principles behind it (i.e. putting some of my data in local arrays, then using barriers to synchronize my work-items), I keep getting the wrong results.

This is an example of how I setup the matrices:

C++

int N = 256; // number of bits in a row/col (or any number that is evenly divisible by 64)
unsigned long long A = new unsigned long long[n*n/64]; // stores bits in 64-bit integers
unsigned long long B = new unsigned long long[n*n/64]; // for example, one row consists of 256 bits and uses 4x64-bit integers to store them
int C  = new int[n*n];

This is the actual formula:
Row i of matrix A is XORed with row j of matrix B. Yes, it is a row to row operation. Then, I count the number of 1s and assign the sum to C[i][j].

This is how I launch the kernel:

C++

const size_t global[2] = { n, n };
clEnqueueNDRangeKernel(queue, kernel, 2, NULL, global, 0, 0, NULL, &event);

This is the actual kernel which works correctly:

C++

__kernel void BitProduct(const int N, const __global ulong* A, const __global ulong* B, __global int* C)
    {
    	const int i = get_global_id(0);
    	const int j = get_global_id(1);
 
    	ulong sum = 0;
 
    	for (int k = 0;k < N/64;k++)
    		sum += popcount( A[ i*(N/64) + k ] ^ B[ j*(N/64) + k ] );
 
    	C[ i * N + j ] = (int) sum;
    }

leon de boer19-Mar-18 23:47

Re: OpenCL bit-matrix multiplication (implementing tiling in local memory)

19-Mar-18 23:47

You can't possibly be using that code it's rubbish and it wouldn't even compile
Even if I assume obvious errors what is left is a really dangerous piece of code that has lethal typecast problems that will blowup in your face

First the array definitions are garbage and can't compile like that and n isn't even defined and you need a pointer for a new array. You have a capital N defined which I assume is supposed to be used for the arrays. So my guess what you meant to type is

C++

int n = 256; // number of bits in a row/col (or any number that is evenly divisible by 64)
unsigned long long *A = new unsigned long long [n*n / 64]; // stores bits in 64-bit integers
unsigned long long *B = new unsigned long long [n*n / 64]; // for example, one row consists of 256 bits and uses 4x64-bit integers to store them

However that just leads us to look at function bitproduct which starts playing around with ulong* pointers.

The usual definition of ulong is an unsigned long which isn't an unsigned long long which the array are created as.
So now I am really confused bitproduct can't be using those arrays because they aren't the right type unless you were
really crazy and forced a typecast at which point all hell breaks out.

So what exactly is a ulong and what is being passed to bitproduct as arrays????
I don't know were to go from there it's a mess.

Now can I make a really strong recommendation to you since you are playing around with fixed bit types that you use the C/C++ standard unit for that.

At the top of your code type
#define <stdint.h>

stdint.h is the standard for fixed width types
<cstdint> (stdint.h) - C++ Reference[^]

Types like long, ints etc are not guaranteed to be a given size on different compilers they vary from compiler to compiler.
However a uint64_t is GUARANTEED to always be exactly 64 bits
I would roll the bit counts into uint16_t

So my guess for sexier and type safe version of what you are doing is

C++

#define <stdint.h>
int n = 256; // number of bits in a row/col (or any number that is evenly divisible by 64)
uint64_t *A = new uint64_t[n*n/64]; // stores bits in 64-bit integers
uint64_t *B = new uint64_t[n*n/64]; // for example, one row consists of 256 bits and uses 4x64-bit integers to store them
uint16_t *C  = new uint16_t[n*n];

_kernel void BitProduct(const int N, const __global uint64_t* A, const __global uint64_t* B, __global uint16_t* C) {

}

In vino veritas

User 1370349220-Mar-18 1:02

Re: OpenCL bit-matrix multiplication (implementing tiling in local memory)

20-Mar-18 1:02

Hi Leon. Thanks for your input.

To clarify, this is an assignment I am working on.

The arrays were set by the instructor, believe it or not, and I am not allowed to modify them. My job is to setup OpenCL and write a kernel that correctly multiplies the two matrices. I know for a fact that my kernel works correctly because the instructor has provided a function that performs the same calculation on the CPU and then compares the two results.

I have uploaded the VS15 project files at https://uploadfiles.io/

leon de boer20-Mar-18 3:12

Re: OpenCL bit-matrix multiplication (implementing tiling in local memory)

20-Mar-18 3:12

It isn't valid C++ code ... Are you seriously telling me you can compile these 3 lines of code on Visual Studio?

C++

unsigned long long A = new unsigned long long[n*n/64]; // stores bits in 64-bit integers
unsigned long long B = new unsigned long long[n*n/64]; // for example, one row consists of 256 bits and uses 4x64-bit integers to store them
int C  = new int[n*n];

I don't care what n is I actually don't know a C++ compiler that will take that.

Visual Studio 2017 will report it correctly that it's missing an all important "*" making it a pointer

Error (active)	E0144	a value of type "unsigned long long *" cannot be used to initialize an entity of type "unsigned long long"	
Error (active)	E0144	a value of type "unsigned long long *" cannot be used to initialize an entity of type "unsigned long long"	
Error (active)	E0144	a value of type "int *" cannot be used to initialize an entity of type "int"

Hence I am still favouring you have typed it wrong because you would be complaining of those errors and I can't believe a lecturer would write that.
Your link isn't correct so I can't look at what I suspect is the real code.

Are you allowed to change BitProduct function to

__kernel void BitProduct(const int N, const __global unsigned long long* A, const __global unsigned long long* B, __global int* C)

That might give you a fighting chance other than that I am pretty sure you are wasting your time and go talk to lecturer.

In vino veritas

modified 20-Mar-18 14:10pm.

User 1370349220-Mar-18 10:09

Re: OpenCL bit-matrix multiplication (implementing tiling in local memory)

20-Mar-18 10:09

Try this link Uploadfiles.io - bitMatrices.rar[^]

leon de boer20-Mar-18 15:27

Re: OpenCL bit-matrix multiplication (implementing tiling in local memory)

20-Mar-18 15:27

At least you now agree you have typo errors which I could only guess at, so we made some progress.
Now can you to go carefully thru the code you typed because there are more errors which I have guessed at Smile | :)

Your code you have posted doesn't appear in the code you have linked so it's really confusing to me what it's relevance?
The code you linked is throwing masses of warnings a couple of them will be fatal if they get called, is this your code or the lecturers?

Lets give you a sample of one of the probably fatal warnings

printf("Program (%d):\n%s\n\n",err,program[p]);

The second parameter is listed as a string %s, what is passed in is a cl_program which is a struct AKA nothing like a string
This is one of the problems with vardiac argument calls they are dangerous, the compiler can't be certain it's fatal but like me it's guessing it is may be fatal or at the least very bad and warning about it. So lets deal with how easy this could be fatal, well if the struct contains no zero's bytes printf is treating the struct as a string so it will keep reading past the struct itself and you are going to get a good old memory access fatal error.

So can we start again, either refer directly to the code you linked or type proper valid code for your question.

I don't mind helping but you have to give me proper valid code to look at.

In vino veritas

modified 20-Mar-18 22:01pm.

User 1370349221-Mar-18 3:50

Re: OpenCL bit-matrix multiplication (implementing tiling in local memory)

21-Mar-18 3:50

All of the warnings are due to the instructor's code. In fact, all of the source code files were provided by the instructor. My task was to modify one of the given functions (in order to setup and launch the kernel) and write the actual kernel.

In spite of the many warnings, were you able to compile and run the code?

leon de boer21-Mar-18 4:25

Re: OpenCL bit-matrix multiplication (implementing tiling in local memory)

21-Mar-18 4:25

Nope it crashes and burns as you would expect given the warnings.

I wasn't going to debug a whole pile of code which I assumed was your homework.

In vino veritas

User 1370349221-Mar-18 7:00

Re: OpenCL bit-matrix multiplication (implementing tiling in local memory)

21-Mar-18 7:00

It is strange that you had to assume this was homework when I explicitly stated that it was on more than one occasion.

leon de boer21-Mar-18 16:12