Messages

16

Système / Re : [SFML2.0]mutex.lock consécutifs, pas de blocage.

« le: Juillet 01, 2012, 09:40:50 pm »

pthread_mutex_trylock rend la main immédiatement avec le code d'erreur EBUSY si le mutex a été verrouillé dans le thread (ou ailleurs).

Ceci permet donc de repérer les erreurs plus facilement.

Donc sinon il va falloir que j'utilise des sémaphores pour rendre un jeton sur un autre thread que celui qui a pris un jeton, ainsi que pour bloquer un thread.

17

Système / Re : [SFML2.0]mutex.lock consécutifs, pas de blocage.

« le: Juillet 01, 2012, 03:57:41 pm »

Un mutex n'est-il pas sensé se baser sur une instruction assembleur TSL ?

Ainsi on lit la valeur contenue dans un registre particulier puis on la remplie d'une valeur aléatoire (!= 0) et ce de manière atomique.

Si la valeur reçu est 0, on entre dans la section critique sinon on rajoute le thread à une liste.

Lors du unlock(), on regarde la liste, si elle est vide, on écrit 0 dans le registre sinon on réveille l'un des thread.


Je ne comprend donc pas pourquoi on ne pourrait pas faire un unlock() sur un thread différent de celui qui a fait le lock.

Ne vaut-il pas mieux d'utiliser des mutex rapides : PTHREAD_MUTEX_INITIALIZER
au lieu de mutex récursifs : PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP

Et d'implémenter une méthode tryLock() qui appellerait la fonction pthread_mutex_trylock ?
(et TryEnterCriticalSection pour windows)

Car tous les ordinateurs ne supporteraient pas les mutex récursifs d'après mes recherches.

Au pire on pourrait utiliser des mutex avec vérifications d'erreurs : PTHREAD_ERREURCHECK_MUTEX_INITIALIZER_NP .

18

Système / Re : [SFML2.0]mutex.lock consécutifs, pas de blocage.

« le: Juillet 01, 2012, 11:42:05 am »

Disons que j'ai une fonction qui fait un mutex.lock qui appelait une fonction qui elle-même appelait une fonction qui faisait aussi un mutex.lock.

Or comme je n'avais pas de deadlock, trouver l'erreur a été beaucoup plus compliqué.
Sachant que l'erreur pouvait ne pas se manifester à chaque coup...

Sinon pour tes cas très particulier, il y a la réunion :

//thread 1
m.lock();
while(1)
{

         n.unlock();
         m.lock(); //attente du thread 2
}

//thread2
n.lock();
while(1)
{

       m.unlock();
       n.lock(); //attente du thread1
}
 

blocage d'un thread :

m.lock();
while(running)
{
       //construction d'un élément quelconque
       while(running && ! bloque)
       {
                //utilisation de l'élément
        }
        //destruction de l'objet
        if(bloque)
                m.lock();
}

//thread2
bloque = true; //blocage
//.....
bloque = false;
m.unlock(); //déblocage
 

Je ne vois pas l'intérêt de ne pas bloquer lors de lock consécutifs.
Si les lock consécutifs sont dû à une erreur, alors on ne résout pas l'erreur, on ne fait que la cacher.
C'est un peu comme un :

try
{

}
catch(..)
{
       //erreur ;-)
}

On empêche juste l'application de planter sur le coup mais rien ne l'empêche de planter plus tard justement à cause de cette erreur.

19

Système / [Résolu][SFML2.0]mutex.lock consécutifs, pas de blocage.

« le: Juin 30, 2012, 07:21:44 pm »

Bonjour,

Je viens de m'apercevoir que plusieurs mutex.lock() consécutifs (testé avec 10 lock consécutifs) ne sont pas bloquants au niveau des lock() suivants le premier alors qu'ils devraient.

    sf::Mutex x;
    for(int i=0; i != 10; ++i)
        x.lock()

Ceci rend donc impossible le blocage d'un thread par lui-même pour être ensuite débloquer par un autre thread.


Dans le cas où les lock consécutifs seraient une erreur, le débogage devient un peu plus compliqué et certaines erreurs pourraient devenir très difficiles à trouver.

Est-ce une erreur ou est-ce voulu?

20

Réseau / Re : [SFML 2.0] Oublie surchages sf::Packet <</>> (U)int64 ?

« le: Juin 16, 2012, 05:09:21 pm »

Désolé, je ne savais pas qu'il y avait une section consacrée à cela sur github.

21

Réseau / [Résolu][SFML 2.0] Oublie surchages sf::Packet <</>> (U)int64 ?

« le: Juin 16, 2012, 03:40:25 pm »

Bonjour,

Je suis actuellement en train de faire passer un hash (= 8 Uint64) grâce à un de vos paquet.
Mais lorsque j'essaye d'extraire ou de mettre un (U)int64 dans le paquet, j'ai une erreur :

/media/Acer/Users/Neckara/Desktop/Donnees/Projet/Serveur/Serveur/administrateur.cpp:137: error: ambiguous overload for ‘operator>>’ in ‘paquet >> password’

Erreur que je n'ai pas avec les (U)int de taille inférieur.

J'ai aussi remarqué ceci :

    /// Overloads of operator >> to read data from the packet
    ///
    ////////////////////////////////////////////////////////////
    Packet& operator >>(bool&         data);
    Packet& operator >>(Int8&         data);
    Packet& operator >>(Uint8&        data);
    Packet& operator >>(Int16&        data);
    Packet& operator >>(Uint16&       data);
    Packet& operator >>(Int32&        data);
    Packet& operator >>(Uint32&       data);
    Packet& operator >>(float&        data);
    Packet& operator >>(double&       data);
    Packet& operator >>(char*         data);
    Packet& operator >>(std::string&  data);
    Packet& operator >>(wchar_t*      data);
    Packet& operator >>(std::wstring& data);
    Packet& operator >>(String&       data);

    ////////////////////////////////////////////////////////////
    /// Overloads of operator << to write data into the packet
    ///
    ////////////////////////////////////////////////////////////
    Packet& operator <<(bool                data);
    Packet& operator <<(Int8                data);
    Packet& operator <<(Uint8               data);
    Packet& operator <<(Int16               data);
    Packet& operator <<(Uint16              data);
    Packet& operator <<(Int32               data);
    Packet& operator <<(Uint32              data);
    Packet& operator <<(float               data);
    Packet& operator <<(double              data);
    Packet& operator <<(const char*         data);
    Packet& operator <<(const std::string&  data);
    Packet& operator <<(const wchar_t*      data);
    Packet& operator <<(const std::wstring& data);
    Packet& operator <<(const String&       data);

Les (U)int64 n'apparaissent pas. Est-ce un oublie?

22

Réseau / Re : [SFML2.0]Timeout des sockets sur un TcpSelector

« le: Juin 14, 2012, 06:43:40 am »

Il faudrait donc que toutes les X secondes j'envoie un socket à chaque client pour vérifier s'il est encore en ligne? ça peut être très lourd.

L'autre solution serait de demander au client d'envoyer régulièrement une requête UDP.
Il faudrait donc qu'à chaque début de connexion j'envois au client un pointeur et que le client me renvois ce pointeur pour trouver plus facilement le socket TCP associé. Mais là il faudra parcourir régulièrement le tableau de socket pour voir les timeouts.

23

Réseau / Re : [SFML2.0]Timeout des sockets sur un TcpSelector

« le: Juin 13, 2012, 10:05:30 pm »

Je me suis mal exprimé.

Le serveur va recevoir des données puis les traiter.

Si le client interromps brutalement la connexion (en dehors d'en send ou receive), par exemple en débranchant sa prise.
Est-ce que niveau serveur je vais recevoir une erreur ou disconnect sur le socket du client (avant de faire un autre send ou receive) ?

24

Réseau / [Résolu][SFML2.0]Timeout des sockets sur un TcpSelector

« le: Juin 13, 2012, 09:42:46 pm »

Bonjour,

J'ai un TcpSelector qui gère plusieurs sockets et j'aimerais que lorsqu'un client ne répond plus, le déconnecter.
J'ai regardé la doc mais je n'ai rien trouvé à ce propos.
Le problème c'est que je ne peux pas faire un thread par client pour utiliser un TcpSelector par socket, niveau performance, c'est intenable.

Parcourir régulièrement une liste de socket pour voir ceux qui sont inactif ne me semble pas très optimisé...

Sinon une autre question que je me pose :
Est-ce que parcourir un tableau de socket après un selector.wait() est vraiment plus optimisé que de faire en sorte que le selector.wait construise une liste de socket ayant reçus des données comme dans la 1.6 ?

EDIT : selon la doc,
Le status indique si le socket est déconnecté, est-ce que la déconnexion prend en compte les timeout ? (il ne me semble pas que le protocole TCP le face, enfin d'après ce que j'ai vu en cours)
S'il prend en compte les timeouts, est-il possible de faire varier la durée au bout de laquelle on considère la connexion perdue?

25

Système / Re : Sémaphore

« le: Juin 13, 2012, 07:46:48 am »

Merci pour votre réponse.

Mais je vois mal comment faire un sémaphore à partir de mutex.

- à chaque nouveau jeton disponible on libère le mutex.
- à chaque nouveau jeton pris on bloque le mutex.

-> mais comment faire si on a des jetons à libérer sans avoir des jetons à prendre ?

C'est pour cela que je pensais à un singleton :

Libérer un jeton :
- on bloque le mutex A
- on incrémente le nombre de jeton disponible
- on libère le mutex B
- on libère le mutex A

Prendre un jeton :
- on bloque le mutex A
- on décrémente le nombre de jeton disponible
- si le nombre de jeton est égal à 0 : on bloque le mutex B
- on débloque le mutex B

Mais après réflexion, le singleton n'est pas nécessaire et une classe pourrait faire l'affaire.

26

Système / [résolut]Sémaphore

« le: Juin 12, 2012, 08:53:04 pm »

Bonjour,

Dans la SFML2.0, il y a des mutex mais pas de sémaphores.

J'aimerais donc savoir s'il vaut mieux utiliser une bibliothèque standard proposant des sémaphores (si oui laquelle ?) ou s'il vaut mieux utiliser des mutex avec une variable globale (en gros un singleton avec 3 méthodes statiques : lock, unlock, et getNbJetons).


Cordialement,
Neckara

27

Graphique / Re : [SFML 2.0]sf::Sprite getPixel

« le: Avril 20, 2012, 05:02:11 pm »

C'est vrai que sauf circonstances extrêmes 60 fois par secondes est très improbable si on utilise un booléen pour savoir s'il y a eu des modifications ou non.

Le seul problème qu'il pourrait subvenir, c'est que la boucle d'affichage est exécutée toutes les 1/60 secondes minimum (et on essaye de s'y tenir au maximum) mais je pense que cela reste très large pour ce qu'on fait.

L'une des "circonstances extrêmes" que j'ai trouvé, c'est une de mes "fenêtres" ( élément graphique spécifique dessiné sur la sf::RenderWindow ) qui serait défini comme l'ensemble de ses éléments (ie pas de "fond", on dessine sur un rectangle transparent et tout ce qui est transparent ne ferait alors pas partie de la fenêtre).

(d'ailleurs ça me donne des idées pour accélérer certaines détections de collisions entre souris et certains éléments de décors fixes)

28

Graphique / Re : [SFML 2.0]sf::Sprite getPixel

« le: Avril 20, 2012, 03:55:04 pm »

Dans des images composées, les éléments seront susceptibles de changer de place.

Donc ceci sera fait au maximum 60 fois par secondes.

Je dis bien au maximum car je pense mettre un booléen pour savoir si une modification a été effectuée dans l'image afin d'éviter des actions inutiles.

29

Graphique / Re : [SFML 2.0]sf::Sprite getPixel

« le: Avril 20, 2012, 03:33:49 pm »

J'ai un peu réfléchis.

Pour les sf::Sprite qui n'ont pour image qu'une image directement chargée directement depuis un fichier, il suffit d'avoir un sf::Texture pour la source et un sf::Image pour les collisions (ou autres)

Mais un sf::Sprite peu aussi être composé (via sf::RenderTexture) de plusieurs images "basiques", pour les collisions cela deviens donc plus compliqué.

D'un côté, à partir des sf::Images, on peut faire des tableaux et essayer de "fusionner" les tableaux en même temps qu'on dessine sur une sf::RenderTexture.

Mais au final, n'est-il pas plus rapide (et plus simple) de faire une getTexture sur le sf::Sprite puis d'obtenir l'image à partir de la sf::Texture ?

Car certes l'accès aux données de la cartes graphiques sont lent, mais d'un autre côté on a plus à "fusionner" les tableaux de pixels nous même ce qui me semble tout de même plus lent qu'un accès en lecture sur la carte graphique.

30

Graphique / Re : [SFML 2.0]sf::Sprite getPixel

« le: Avril 18, 2012, 03:17:50 pm »

Donc pour construire mon tableau de collision, il vaut mieux enregistrer l'image temporairement dans une sf::Image puis à partir de la sf::Image faire une sf::Texture ou faire directement la sf::Texture puis passer par un sf::Image pour construire mon tableau?