|
Cyrilix wrote: - Using fibers to emulate explicit wait API calls (WaitForSingleObject, etc.) so that waits essentially cause a switch to a different threadpool task, until the wait is ready.
Requires you to emulate kernel waits (presuming you have more than one fiber per thread in the threadpool), or do you effectively poll the kernel objects on fiber context switches (oh, and you'll need to schedule them yourself somehow).
Cyrilix wrote: - Optimizing a threadpool by using more threads than can be efficiently used concurrently.
That sounds a lot simpler - maybe you can detect thread state and automatically add new threads to the pool as other threads enter wait states? And then reduce the number of active threads appropriately when the waits terminate?
Personally, my feelings about concurrency have been significantly influenced by the concurrency approaches of other programming[^] langauges[^]. Both those languages are functional, which avoids the problems of sharing data between threads. Erlang uses an actor model[^] of concurrency, while Haskell has several concurrency models. I think utilising the best approaches of those different models could offer significant improvements in achieving concurrency capable of making best use of multiple processing cores.
One other thought - for something a bit simpler, emulating the tasking model of Ada with C++ and threads might be an interesting challenge. Ada tasking has been knocking around since the early 1980s and is still (IMO and in many other people's opinions) a significantly better model of concurrent programming than basic threads.
Anyway - that may be of use, maybe not - I hope there's something coherent in there!
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I don't exactly have a game plan for how I will handle fibers and waits so part of the task would be for me to see if the Windows API has any kind of built-in support for this. If I can somehow accomplish that, then I don't think the scheduling would be a problem because I can use a simple algorithm as proof-of-concept. As for the second idea, something like what you suggest will definitely be in the works. I'm actually a bit skeptical as to whether or not I'll see any major improvements here, but sometimes I surprise myself.
In terms of other languages and their concurrency approaches, that's probably something I'll want to look at if I have time, so I'll keep it in mind.
Thanks.
Edit: I gave some thought to what you said about the Ada task model vs. C++ and threads, and it seems to me like different concurrency models must still be implemented at the base with C++ or assembly. I guess the question then becomes, how do you use lower-level languages to implement a higher-level concurrency model. I think what I'm essentially trying to do here is to refine a higher-level task-based model by using something like threads.
modified on Sunday, July 12, 2009 8:23 PM
|
|
|
|
|
just wondering but does windows give u that type of control without writing a kernel mode driver type app? regarding fibre management etc. because i'm sure that windows has a system that deals with this so your going to be overriding it to a certain level.
or am i thinking about the wrong tangent?
|
|
|
|
|
I've never worked with fibers so I don't actually know. I see that they have a neat little API for some of the stuff that I might want to do, but that may not be sufficient. With respect to working with fibers, I'm starting from ground zero here.
I've also read a lot of articles warning very heavily against their usage, bugs, limitations, and etc. It's not too encouraging but still tempting, which is why I ask for some feedback.
|
|
|
|
|
ahh a fellow explorer not afraid of the dark or the unknown excellent, may i suggest running these apps on a spare PC...
i am having flash backs to when i started COM programming, my GUID registry entries would have won an award for coding horrors, and windows took about 35mins to boot up hahah the good ol days
|
|
|
|
|
#define R_GLDRAWELEMENTS 0x5ED02FD4
WINAPI _R_glDrawElements(GLenum mode, GLsizei count, GLenum type, const GLvoid *indices);
WINAPI (*R_glDrawElements)(GLenum , GLsizei , GLenum , const GLvoid *) = (void (__stdcall*) (unsigned int,int,unsigned int,void const *)) R_GLDRAWELEMENTS;
WINAPI _R_glDrawElements(GLenum mode, GLsizei count, GLenum type, const GLvoid *indices)
{
_R_glDrawElements( mode, count, type, indices);
}
The 3 line of code gives a bad error error C2059: syntax error : '('
And i dont know what is wrong with it the brackets seems to be all in place....
|
|
|
|
|
I'm not 100% sure how you didn't get other compiler errors, to be honest. I get errors where you've used WINAPI, as that doesn't (on my Windows installation) specify a return type - I have #define WINAPI __stdcall - just a calling convention.
Also - in the body of _R_glDrawElements, you call _R_glDrawElements recursively - that'll cause a stack overflow. Did you really mean R_glDrawElements??
Anyway - try this (modulo changing the body of _R_glDrawElements if I was correct above)
#define R_GLDRAWELEMENTS 0x5ED02FD4
void WINAPI _R_glDrawElements(GLenum mode, GLsizei count, GLenum type, const GLvoid *indices);
void (WINAPI* R_glDrawElements)(GLenum , GLsizei , GLenum , const GLvoid *) = (void (__stdcall*) (unsigned int,int,unsigned int,void const *)) R_GLDRAWELEMENTS;
void WINAPI _R_glDrawElements(GLenum mode, GLsizei count, GLenum type, const GLvoid *indices)
{
_R_glDrawElements( mode, count, type, indices);
}
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
In addition to Stuart's reply, it is recommended to type define function pointers.
It makes the code all the more readable.
typedef void (WINAPI* PFN_GLDRAWELEMENTS)(GLenum , GLsizei , GLenum , const GLvoid *);
PFN_GLDRAWELEMENTS R_glDrawElements = (PFN_GLDRAWELEMENTS)R_GLDRAWELEMENTS;
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
I tryed your methods but it dosent work ....
typedef VOID (WINAPI* R_glDrawElements_) (GLenum , GLsizei , GLenum , const GLvoid *);
R_glDrawElements_ pR_glDrawElements = 0x5ED02FD4;
And doing this i get error
C:\Documents and Settings\ivor\Desktop\test5\Client.cpp(23) : error C2440: 'initializing' : cannot convert from 'const int' to 'void (__stdcall *)(unsigned int,int,unsigned int,const void *)'
|
|
|
|
|
nah1337 wrote: R_glDrawElements_ pR_glDrawElements = 0x5ED02FD4;
You need the typecast here.
R_glDrawElements_ pR_glDrawElements = (R_glDrawElements_)0x5ED02FD4;
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
Hello again thnx for previous replay well i still struggling with it and now i dosent just understand why i get the error i dont change anything after typedef ....
typedef VOID (WINAPI* R_glDrawElements_) (GLenum , GLsizei , GLenum , const GLvoid *);
R_glDrawElements_ pR_glDrawElements = (R_glDrawElements_)0x5ED02FD4;
VOID WINAPI R_glDrawElements_(GLenum mode, GLsizei count, GLenum type, const GLvoid *indices)
{
R_glDrawElements_( mode, count, type, indices);
}
C:\Documents and Settings\ivor\Desktop\test5\Client.cpp(56) : error C2377: 'R_glDrawElements_' : redefinition; typedef cannot be overloaded with any other symbol
C:\Documents and Settings\ivor\Desktop\test5\Client.cpp(27) : see declaration of 'R_glDrawElements_'
|
|
|
|
|
Hi
When I tried to delete a class instance, I got the error message"HEAP: Heap block at 003BCB48 modified at 003BCC6C past requested size of 11c".
What is wrong?
Best regards,
|
|
|
|
|
You allocated a block of memory, some 284 bytes in size, and then accessed something just beyond the end of the chunk that was given to you, at offset 292.
This snippet is likely to cause a similar error:
char* p=malloc(284);
p[292]=0;
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
You wrote past the end of the object somehow. The heap manager in debug mode puts sentinel values before and after allocations and checks these when you deallocate the memory. If the sentinel values have changed, it means you've written into memory you shouldn't have done.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
To expand on what I said earlier, the problem will typically show when the memory manager checks the borders of yout allocation, so if your code would look like:
CMyclass * pCMyclass = new CMyclass ();
...
delete pCMyclass;
then the problem would occur when executing the delete statement, although the error could be anywhere in the CMyclass object.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Please tell me how function call is resolve, how vptr works in this case CODE:
class base
{
public:
virtual void f1()
{
cout<<"base f1";
}
virtual void f2()
{
cout<<"base f2";
}
};
class d1: public base
{
public:
virtual void f1()
{
cout<<"d1's f1";
}
virtual void f2()
{
cout<<"d1's f2";
}
};
class d2: virtual public base,virtual public d1
{
public:
d2()
{
cout<<"d2 class construxtor\n";
}
~d2()
{
cout<<" d2 class destructor\n";
}
};
void main()
{
clrscr();
base* obj= new d2;
obj->f1();
obj->f2();
}
modified on Sunday, July 12, 2009 2:46 PM
|
|
|
|
|
vptrs don't come into it - you have no virtual functions, so therefore there will be no vtable.
If the compiler was able to construct your base pointer obj (it can't because it inherits from base twice - which one should it upcast through?), there would be no runtime resolution of f1 and f2 ; they're non-virtual functions, so they will be resolved using the static type of obj , i.e. base . That means that the program (if it could compile) would output base f1base f2
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Actually the code will (and does) compile. Note that base is inherited virtually (note the use of virtual public base in the declaration of class d2 ). This ensures that only one version of the base class will be included in d2
However, you are completely correct in that there is no vtable, and the output wil be base f1base f2 .
Graham
Librarians rule, Ook!
|
|
|
|
|
Better tell that to gcc, then - it gives this warning and error:
a.cpp:30: warning: direct base ‘base’ inaccessible in ‘d2’ due to ambiguity
a.cpp: In function ‘int main()’:
a.cpp:46: error: ‘base’ is an ambiguous base of ‘d2’
VC++ 2008 agrees
a.cpp(30) : error C2584: 'd2' : direct base 'base' is inaccessible; already a base of 'd1'
a.cpp(5) : see declaration of 'base'
a.cpp(16) : see declaration of 'd1'
The virtual qualifier needs to be applied to all inheritance instances of the shared base, so you need this code for it to compile (note virtual wherever 'base' is inherited):
class base
{
public:
void f1()
{
cout<<"base f1";
}
void f2()
{
cout<<"base f2";
}
};
class d1: virtual public base
{
public:
void f1()
{
cout<<"d1's f1";
}
void f2()
{
cout<<"d1's f2";
}
};
class d2: virtual public base, public d1
{
public:
d2()
{
cout<<"d2 class construxtor\n";
}
~d2()
{
cout<<" d2 class destructor\n";
}
};
int main()
{
base* obj= new d2;
obj->f1();
obj->f2();
}
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
OK, you caught me.
That'll learn me not to trust VS2005
Graham
Librarians rule, Ook!
|
|
|
|
|
Graham Shanks wrote: VS2005
That compiled in VS2005? I guess I can understand why, I think. Maybe.
Also yet another example why it's good to keep clear of tricksy inheritance features in C++. a) the programmer isn't 100% sure what should happen (I'm definitely including myself in that group), and b) neither's the compiler.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Stuart Dootson wrote: That compiled in VS2005?
No. Doesn't compile in VS 2005, 2008 or VC++ 6.0.
|
|
|
|
|
The code doesn't compile with VC++ 6.0, VS 2005 and VS 2008.
(clrscr() is also undeclared in Visual C++; I vaguely recall it being in Turbo C. Perhaps he has an early version of Turbo C++ and it's not showing this as an error.)
|
|
|
|
|
all right I got it...but if I am making f1() and f2() virtual in base class and d1 class, how vptr will work?
|
|
|
|
|
As base is declared virtual, there is one instance of base in d2. This means (IIUC) that the functions in d1 will hide the functions in base from the point-of-view of d2 because d1 is more derived than base.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|